
Percebi que em várias distribuições Linux, sempre que um novo usuário é criado, ele é atribuído a um grupo primário com seu próprio nome.
por exemplo. Se eu criar um usuário chamado "testuser", por padrão ele será atribuído ao grupo primário "testuser".
Isso faz com que todos os usuários tenham seus próprios grupos primários exclusivos. Todos esses grupos também teriam apenas 1 usuário, pois não faria sentido adicionar outros usuários a esses grupos. Isto é um tanto contra-intuitivo, pois "grupo" geralmente significa "mais de 1".
Esses grupos primários de usuários também são geralmente inúteis ao tentar atribuir permissões a arquivos/pastas.
Existe algum motivo para esse ser o comportamento padrão nas distros? E algum caso de uso em que esse comportamento seja realmente útil? Por que não atribuir todos os novos usuários a um grupo primário de "usuários"?
Responder1
A razão (a única razão, até onde eu sei) para colocar os usuários em um grupo próprio é criar umask 002
um umask 007
padrão sensato.
Oumaské uma máscara para as permissões padrão dos arquivos recém-criados. O significado dos dígitos é o mesmo de chmod
; o primeiro dígito é para o usuário, o segundo para o grupo e o terceiro para os demais. Se um bit for 1 na umask, ele será removido (mascarado) das permissões do arquivo recém-criado. Por exemplo, se um aplicativo criar um arquivo não executável sem nenhum requisito específico de privacidade¹, ele passará 666 como as permissões do arquivo, e a aplicação do umask 002 resultará em um arquivo com permissões 664 ( 0666 & ~002
em notação semelhante a C), ou seja, um arquivo que pode ser lido por todos e gravável apenas pelo usuário e pelo grupo ( rw-rw-r--
).
Com o umask 022, os arquivos são legíveis por todos por padrão, mas apenas graváveis por seu autor. Com o umask 002, os arquivos também podem ser gravados pelo grupo que os possui. Se o grupo principal dos usuários for aquele em que eles são o único usuário e o umask for 002, então:
- Por padrão, os arquivos só podem ser gravados por seu autor, porque embora as permissões sejam
rw-rw-r--
, não há outro usuário no grupo que tenha permissões de gravação. - Para permitir que um arquivo seja modificado por membros de um grupo, o autor só precisa torná-lo propriedade desse grupo com a extensão
chgrp
. Isso pode até acontecer automaticamente se o arquivo for criado em umdiretório com o bit setgidou um equivalenteLCA.
A vantagem sobre o 022 umask é que nessa configuração, para tornar um arquivo editável pelos usuários, o autor deve fazer duas coisas: definir o grupo e estender as permissões ( chmod g+w
). As pessoas tendem a esquecer este segundo passo (ou único passo, em um diretório setgid).
¹ Exemplos de arquivos com requisitos específicos de privacidade: chaves de criptografia; e-mails; qualquer arquivo em um diretório público, como /tmp
.
Responder2
Era costume adicionar todos os usuários ao grupo users
, mas isso tornava estranho o compartilhamento de arquivos de forma controlada (abra as permissões do grupo, todos têm acesso). Como hoje um processo pode pertencer a vários grupos ao mesmo tempo, basta fechar o acesso dando a cada usuário seu próprio grupo, e compartilhar arquivos adicionando grupos explícitos para isso. Ou (se disponível) useACLs.