Contas de usuário(a)

Contents

  1. Contas de usuário(a)
  2. Parte básica e histórico
    1. Como as senhas são armazenadas
  3. Nós temos essas ferramentas no Debian
    1. adduser
    2. src:shadow
    3. systemd
    4. métodos não tradicionais de gerenciamento de contas de usuário(a)
      1. LDAP
      2. Active Directory
      3. NIS
  4. Criando usuários(as)
    1. Escolhendo um nome de usuário(a) ou grupo
      1. Debian
        1. restrições gerais
        2. contas de sistema
        3. contas de usuário(a) regulares
  5. Nomes de usuário(a) válidos
  6. Pacotes auxiliares que interagem com usuários(as) e grupos
    1. base-passwd
    2. dpkg
    3. systemd-sysusers
    4. libc
    5. pam
    6. Política Debian
  7. Links

Parte básica e histórico

Em um sistema operacional Unix (e em muitos outros sistemas operacionais não Unix), um(a) usuário(a) do computador é obrigado(a) a se autenticar para que o sistema operacional possa rastrear (ou responsabilizar) seu uso do computador. Esta conta pode ser rastreada até a própria pessoa quando o sistema operacional é auditado. Os nomes das contas de usuário(a) servem como identificadores exclusivos para usuários(as) que interagem com o sistema.

As entidades em sistemas Unix e semelhantes, como GNU/Linux e Debian, são chamadas de usuários(as) (mais exatamente, contas de usuário(a)) e groups. Usuários(as) e Grupos têm nomes alfanuméricos e são mapeados em software de sistema para IDs numéricos (comumente chamados de id de usuário, uid e id de grupo, gid). O núcleo Linux não tem noção dos nomes alfanuméricos e lida apenas com IDs numéricos. O "banco de dados" que contém essas informações é tradicionalmente um arquivo texto como /etc/passwd, /etc/shadow, /etc/group e /etc/gshadow. Consulte passwd(5) e outras páginas de manual associadas para a documentação detalhada do formato.

É importante notar que a documentação não diz qual tamanho um nome de usuário(a) deve ter e qual tipo de codificação está sendo usado. Contudo, há limites técnicos:

Enquanto outros sistemas operacionais, como os BSDs, podem compilar o banco de dados de usuários(as) de arquivos texto para bancos de dados de algum tipo, o Debian e a maioria dos outros sistemas operacionais baseados em GNU/Linux usam os arquivos texto diretamente.

Como as senhas são armazenadas

Tradicionalmente, /etc/passwd mantinha as senhas associadas diretamente aos(às) usuários(as) e grupos. Um hash "salgado" (salted hash) da senha substituiu as senhas de texto simples rapidamente. O arquivo passwd regular deve ser legível para qualquer pessoa, ou não seria possível para ferramentas como ls exibir os nomes alfanuméricos de proprietários(as) de arquivos e diretórios. Como os ataques de força bruta de hashes tornaram-se possíveis, os hashes de senha foram movidos para um arquivo dedicado, /etc/shadow, que poderia ser restrito a ser legível apenas para processos privilegiados.

Ter senhas diretamente em /etc/passwd ainda é configurável, mas não tem sido amplamente utilizado, pelo menos desde meados de 1990. Recomenda-se deixar a respectiva configuração em seu padrão, mantendo as senhas em /etc/shadow, de propriedade de root:shadow, com um modo de acesso de 0640.

Nós temos essas ferramentas no Debian

adduser

As ferramentas específicas do Debian para adicionar e remover uma conta são adduser e deluser do pacote adduser. Essas ferramentas atuam como uma interface para as ferramentas de baixo nível e têm inteligência para honrar as especialidades do Debian. Eles são configuráveis para que você possa adaptá-las às suas políticas e necessidades locais. Elas oferecem diferentes modos de operação para contas de usuário(a) local (para uso pelo(a) administrador(a) local) e para contas do sistema (principalmente para uso por mantenedores(as) de pacotes para criar contas relacionadas a pacotes durante a instalação do pacote, mas também, é claro, utilizáveis livremente para o(a) administrador(a) local).

adduser é mantido no Salsa como um pacote Debian nativo.

A maioria dos derivativos Debian e ?PureBlends também usam adduser e deluser do Debian. Outros sistemas operacionais podem ter suas próprias implementações, provavelmente até mesmo usando os mesmos nomes, mas com uma sintaxe diferente.

O adduser é configurável sobre o que torna válido um nome de usuário(a) de sistema ou de não sistema (regular), mas ele se baseia em src:shadow para efetivamente criar a conta. E src:shadow tornou-se mais restritivo em suas regras no final de 2024, e não é configurável. Assim, a configurabilidade do adduser não faz mais sentido.

src:shadow

A maioria das ferramentas de baixo nível usadas para gerenciar contas de usuário(a) e senhas que fazem interface direto com o banco de dados do usuário(a) vem do pacote passwd:

Uma vez que o pacote-fonte do passwd é chamado de shadow, sem construir um pacote binário com esse nome por razões históricas, o pacote-fonte é frequentemente referenciado como src:shadow para evitar confusão.

Essas ferramentas têm a reputação de serem de baixo nível, mas evoluíram para serem quase tão completas quanto adduser. Elas provavelmente existirão e funcionarão em sistemas não Debian também, talvez com um conjunto de recursos diferentes devido à longa história deste pacote.

src:shadow tem um(a) Upstream] que não está associado(a) ao Debian. Os pacotes Debian são mantidos no Salsa também.

src:shadow no Debian foi alterado para atender às necessidades e políticas especiais do Debian. Há um esforço para reduzir a quantidade de tais patches, que começou com o ciclo de desenvolvimento do Trixie/Debian 13.

src:shadow é meio que a autoridade na definição do que é válido sobre nomes de usuários(as)/grupos. É projetado para ter uma configurabilidade bastante limitada e está sendo usado em outros sistemas operacionais. O Debian tem influência limitada nessas decisões.

systemd

systemd faz interface com o banco de dados dos(as) usuários(as) por meio de systemd-sysusers, que é uma maneira declarativa de criar contas de sistema, e systemd-homed, que introduz uma nova maneira de lidar com os diretórios home dos(as) usuários(as). Outras partes do systemd também interagem com o banco de dados dos(as) usuários(as).

systemd tem sua própria visão sobre o que consiste em um nome de usuário(a) válido, que é mais rigoroso do que o nosso método em alguns aspectos, e mais relaxado em outros. Veja abaixo um link para a documentação relevante do systemd.

métodos não tradicionais de gerenciamento de contas de usuário(a)

Se você usar métodos não tradicionais de gerenciamento de contas de usuário(a), precisará de ferramentas diferentes que talvez venham a ser abordadas aqui. Voluntariar-se para escrever esses capítulos será muito apreciado.

LDAP

insira o texto aqui

Active Directory

insira o texto aqui

NIS

Entende-se que o NIS está indo embora. Alguns pacotes já removeram seus recursos NIS. Devido à falta de manutenção, você deve estar disposto(a) a oferecer suporte se quiser manter o NIS no Debian.

Criando usuários(as)

Desenvolva um texto sobre as diferenças entre as abordagens declarativa, do adduser e do useradd.

Escolhendo um nome de usuário(a) ou grupo

A escolha do nome do(a) usuário(a) e do grupo pode variar de prático e direto a não convencional e bizarro. Existem inúmeras convenções independentes e às vezes contraditórias para escolher nomes de usuário(a). A segurança também desempenha um papel aqui, já que caracteres estranhos no nome de usuário(a) podem levar a vulnerabilidades de segurança.

O Framework PRECIS ("Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols" - Preparação, Execução e Comparação de Strings Internacionalizadas em Protocolos de Aplicação) está documentado em alguns RFCs listados abaixo e fornece conselhos e diretrizes importantes sobre como lidar com nomes de usuário(a). Adduser não deu muita atenção a isso até recentemente.

Debian

O Debian tem formalmente dois tipos de contas e nomes de contas: contas de sistema e contas de usuário(a) não sistema (regulares). Essas distinções estão principalmente em diferentes faixas de UIDs/GIDs numéricas e em diferentes regexes aplicadas para permitir/não permitir caracteres na conta e nos nomes de grupo.

restrições gerais

Algumas restrições devem ser aplicadas a todos os tipos de nomes de usuário(a) e grupos por razões técnicas e de segurança. Por exemplo, os dois pontos (:) são usados em /etc/passwd como um separador de campo e as especificações não contêm nenhuma linguagem para escape, por isso é amplamente aceito que um nome de usuário(a) não deve conter dois pontos. Algumas ferramentas que leem /etc/passwd consideram a barra invertida como um caractere de escapa, outras não. Além disso, o nome de usuário(a) é geralmente usado como parte do caminho para o diretório home e, portanto, não deve conter caracteres que possam ser problemáticos em nomes de arquivos, como barras.

Por razões de segurança, caracteres que podem ser usados para injeção de código em vários scripts (marcas de pontuação, espaços em branco) também devem ser evitados porque, é claro, nomes de usuário(a) são processados de várias maneiras em scripts e programas escritos em uma ampla variedade de linguagens de programação.

Caracteres que podem confundir (ou controlar) dispositivos de saída são outra má ideia em um nome de usuário(a). Isso inclui os caracteres de controle clássicos, como alimentação de linha (line feed), retorno de carro (carriage return) ou alimentação de folha (form feed), mas também caracteres de controle Unicode, como caracteres combinantes e/ou caracteres de controle da direita-para-esquerda.

Para evitar confusão com UIDs numéricos, nomes de usuário(a) que consistem inteiramente de dígitos são problemáticos. Começar com um traço pode confundir nomes de usuário(a) com opções de linha de comando, e também com números negativos.

Dito isto, alguns casos difíceis criam conflitos; por exemplo, algum site quer usar endereços de e-mail (contendo @) como nomes de usuário(a), enquanto nas instalações do Windows/Samba, cifrões e barras invertidas são comuns em nomes de usuário(a). Pontos em nomes de usuário(a) geralmente separam nomes e sobrenomes, mas são, por exemplo, problemáticos em scripts shell (principalmente em chown, que mudou sua sintaxe de usuário(a).grupo para usuário(a):grupo por esse motivo).

Espaço em branco dentro dos nomes de usuário(a) é tecnicamente possível mesmo no PRECIS, mas isso fará com que milhares de scripts shell sejam quebrados.

No Debian (e na maioria das outras distribuições Linux), os nomes de usuário(a) são sensíveis a maiúsculas ou minúsculas (case sensitive).

O tamanho dos nomes de usuário(a) também é um problema.

A criação de nomes de usuário(a) contendo caracteres Unicode como ä ou ꭥ é possível no Debian 12. No entanto, nenhuma normalização é feita em tais nomes de usuário(a), que levarão a comportamentos não intencionais e possíveis riscos de segurança.

Algumas restrições de sanidade básicas adicionais devem ser adotadas e aplicadas. Nenhuma das sugestões do PRECIS e/ou do projeto systemd é totalmente adequada para o Debian, então precisamos fazer nossa própria definição.

Faz sentido, pelo menos, não permitir:

src:shadow upstream aplica este conjunto de regras restritivas:

Faz sentido usar as mesmas regras para nomes de grupo.

contas de sistema

As contas do sistema são aquelas que estão no banco de dados de usuário(a) padrão como criadas e mantidas automaticamente pelo base-passwd, e aquelas criadas na instalação de pacotes a partir dos scripts dos(as) mantenedores(as).

adduser restringe as contas do sistema de forma bastante severa. Os nomes das contas do sistema devem começar com uma letra minúscula ou sublinha, seguido por letras minúsculas, dígitos, sublinhas e traços. Há um comprimento máximo de 32 caracteres.

Um(a) administrador(a) local pode alterar os conjuntos de caracteres aceitos, mas alterar para um conjunto de caracteres mais restritivo pode fazer com que a instalação de pacotes falhe. Há apenas testes mínimos para esses casos; administradores(as) que decidam quebrar seus sistemas dessa forma terão que juntar todas as peças. Além disso, a configuração do adduser para aceitar caracteres estranhos provavelmente só resultará no useradd subjacente rejeitando o nome de usuário(a).

A política sugere que os nomes de contas pertencentes a um pacote sejam prefixados com uma sublinha para evitar colisões de espaço de nome. Pacotes mais antigos podem usar outros métodos para evitar isso, como prefixar com Debian-. Pacotes existentes não precisam mudar para a nova convenção. Atualmente não há discussão no Debian para mudar isso. Acredita-se amplamente que o estado atual de política e do código sejam uma solução boa e prática.

contas de usuário(a) regulares

Contas de usuário(a) regulares (não sistema) são aquelas que podem estar associadas a pessoas, funções ou papeis da vida real, e estão sob o controle do(a) administrador(a) local.

O adduser impõe restrições menos rígidas a elas por padrão e pode ser configurado para aceitar nomes de usuários(as) a critério do(a) administrador(a) local. As restrições do useradd ainda se aplicam.

O comportamento do adduser pode ser influenciado pela opção --allow-bad-names, que enfraquece a verificação de nome de usuário(a), e a opção --allow-all-names, que apenas passa o nome de usuário(a) selecionado para useradd, deixando a decisão de aceitar o nome ou não para o useradd. Não está claro se isso é uma boa ideia.

Nomes de usuário(a) válidos

Este capítulo deve cobrir o que o Debian considera um nome de usuário(a) válido e incluirá informações sobre o que esperamos que funcione e o que sabemos que não funciona. Se coloca de alguma forma entre documentar o estado atual das coisas e para onde queremos ir. Infelizmente, ainda é um trabalho a ser feito.

No Debian, parece que o nome de usuário(a) em /etc/passwd é ingenuamente codificado em UTF-8. Portanto, é possível criar contas com um nome de usuário(a) em Unicode. Alguns caracteres Unicode podem ser mais longos do que um byte na forma codificada e, portanto, reduzem o tamanho possível do nome de usuário(a) (cujos limites devem ser considerados em bytes, não em caracteres). No entanto, nenhuma canonização é feita para os nomes de usuário(a) que causam vários problemas descritos abaixo.

Há uma lacuna de especificação perceptível, e o comportamento atual foi determinado empiricamente. Ferramentas podem mudar o comportamento no futuro.

Em novembro de 2024, houve uma discussão sobre este tópico na debian-devel, que também obteve alguma cobertura em Linux Weekly News. O principal resultado dessa discussão foi que o mantenedor do adduser voltou atrás de sua ideia de permitir oficialmente nomes de usuário(a) em UTF-8, shadow considerando apertar suas restrições de nomes de usuário(a), e adduser acompanhando as decisões.

Há uma Proposta de Padrão Internet (RFC 8265) que afirma que um nome de usuário(a) deve conter apenas os caracteres listados na ?IdentifierClass (RFC 8264, Seção 4.2). adduser deverá provavelmente alterar seu modo de operação padrão, se for possível utilizar uma expressão regular.

?IdentifierClass, de acordo com a RFC 8264, é:

Temos que discutir:

Atualmente, não está claro como destilar esses pontos em um regexp perl e quais casos de teste devem ser aplicados.

Pacotes auxiliares que interagem com usuários(as) e grupos

Este capítulo contém uma lista de pacotes (-fonte) que estão afetando esta página, contas de usuário(a), grupos, e são afetados de volta. Mantenedores(as) desses pacotes, por favor, marquem seu pacote em itálico se estiverem cientes desta página Wiki e em negrito se estiverem dispostos(as) a participar com a manutenção desses documentos e a adaptar seus pacotes de acordo. Se você tem uma página para o seu pacote nesta Wiki, por favor, link aqui.

base-passwd

O base-passwd contém as cópias-mestras canônicas dos arquivos do banco de dados de usuário(a)(/etc/passwd e /etc/group), contendo as IDs de usuário(a) e grupo alocados pelo Debian.

dpkg

Embora o dpkg atualmente não interage com o banco de dados de usuários(as), os(as) mantenedores(as) planejam fazê-lo no futuro. Veja Teams/Dpkg/Spec/SysUser para mais detalhes.

systemd-sysusers

systemd oferece um modo declarativo para criar contas de sistema em tempo de execução.

libc

libc contém várias rotinas de bibliotecas que fazem interface com o banco de dados de usuário(a), permitindo mapear nomes de usuários(as) e grupos para usuários(as) e grupos.

pam

pam desempenha muitos papéis aqui também. Por favor, considere despejar seu conhecimento aqui.

Política Debian

O Manual da Política Debian contém em seu Capítulo 9.2 algumas informações sobre nomes de usuários(as) e grupos. Uma vez que cobre apenas o lado do empacotamento e deliberadamente deixa coisas em aberto para discussão e definição adicionais, esta página existe.

Links

CategorySystemSecurity | CategorySystemAdministration