Por que usuários recém-criados são atribuídos a grupos primários de seus nomes de usuários?

Question

Tenho notado que, em várias distribuições do Linux, sempre que um novo usuário é criado, ele é atribuído a um grupo principal de 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. Isso é um pouco contra-intuitivo, já que "grupo" geralmente significa "mais de 1".

Esses grupos principais de usuários também são geralmente inúteis ao tentar atribuir permissões a arquivos / pastas.

Existe alguma razão para este comportamento padrão nas distros? E qualquer caso de uso em que esse comportamento é realmente útil? Por que não atribuir todos os novos usuários a um grupo principal de "usuários"?

    

Answer 1

O motivo (o único motivo, até onde eu sei) para colocar os usuários em um grupo próprio é tornar umask 002 ou umask 007 um padrão sensato.

A umask é uma máscara para as permissões padrão de arquivos recém-criados. O significado dos dígitos é o mesmo que em chmod ; o primeiro dígito é para o usuário, o segundo para o grupo e o terceiro para os outros. Se um bit for 1 no 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 particular de privacidade, ele passará 666 como as permissões de arquivo, e o aplicativo da umask 002 resultará em um arquivo com permissões 664 ( 0666 & ~002 em C-like notação), ou seja, um arquivo legível por todos e gravável apenas pelo usuário e grupo ( rw-rw-r-- ).

Com o umask 022, os arquivos são legíveis por padrão, mas podem ser gravados pelo autor. Com a umask 002, os arquivos são adicionalmente graváveis pelo grupo que os possui. Se o grupo primário dos usuários é aquele em que eles são o único usuário, e o umask é 002, então:

• Por padrão, os arquivos só podem ser gravados pelo 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 de propriedade desse grupo com chgrp . Isso pode até acontecer automaticamente se o arquivo for criado em um diretório com o bit setgid ou um equivalente ACL .

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 particulares de privacidade: chaves de criptografia; e-mails; qualquer arquivo em um diretório público, como /tmp .}

    

Answer 2

Era costume adicionar todos os usuários ao grupo users , mas isso torna estranho o compartilhamento de arquivos de maneira controlada (abrir permissões de grupo, todo mundo tem acesso). Como hoje um processo pode pertencer a muitos grupos no momento, 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) use ACLs .