Por que o valor padrão umask para useradd no openSUSE está configurado para 022?

Question

Eu criei recentemente um ambiente de teste muito simples com o openSUSE.

Como tentei configurar um diretório compartilhado, sem usando ACLs, mas com SetGID nesse diretório, por algum motivo, notei que o padrão umask para cada usuário é definido como 022 (ou seja, 755 nos diretórios e 644 nos arquivos).

Isso é feito em /etc/login.defs .

Estou acostumado com uma umask 002 (ou seja, 775 diretórios / 664 arquivos) para usuários normais e 022 para o usuário-raiz.

Devo alterar o valor umask para useradd no arquivo mencionado acima, se eu quiser defini-lo como padrão para todos os useradds futuros e como posso alterar o umask para todos os usuários existentes em meu sistema (exceto a conta root, de claro)?

    

Answer 1

Respondendo a pergunta em seu assunto: O OpenSuSE usa a tradicional configuração Unix umask , em vez da inspirada pelo Debian adotada por algumas outras distribuições Linux.

A edição de /etc/login.defs deve ser suficiente para alterá-lo; isso não afetará os usuários atualmente conectados, e não há nenhuma maneira de você forçar essa mudança nos programas que estão atualmente em execução. Ele também não afetará os usuários que o substituíram em ~/.profile (ou .bash_profile , .login , etc. conforme o shell).

useradd não está envolvido com isso; é uma configuração por processo e o padrão é definido durante o login (por isso, login.defs e não /etc/default/useradd ).

    

Answer 2

O umask 022 (ou 0022 ) é a umask comumente usada para sistemas UNIX que usam o estilo tradicional de gerenciamento de contas de usuário . No estilo tradicional de gerenciamento de contas, quando um usuário é criado, o usuário recebe um grupo padrão que seria algo como uma equipe ou departamento, ou talvez tão simples quanto "usuários". Os diretórios setgid (poderíamos chamá-los de "diretórios de equipe") não funcionam como esperado, porque os arquivos não podem ser gravados por outros membros da equipe, a menos que o usuário os torne explicitamente graváveis. Isso não é muito prático, especialmente quando os arquivos são opacos para o usuário, como seria o caso, por exemplo, de um repositório git. Isso não é considerado um problema porque as ACLs fornecem uma solução perfeita para isso.

O umask 002 (ou 0002 ) é a umask comumente usada para sistemas UNIX que usam UPG - User Private Groups . Ao adicionar um usuário em um sistema UPG, o sistema cria um grupo com o mesmo nome e id de grupo que o nome do usuário e o ID do usuário. UPG é uma abordagem inspirada pelo Debian de gerenciamento de contas de usuários. Como você acabou de experimentar, o UPG tem algumas vantagens quando se trata de diretórios setgid - contanto que os usuários não sobreponham sua umask. As ACLs estão protegidas dessa substituição.

A melhor solução é refatorar suas contas de usuário e grupo e ativar o UPG, então você está "seguro".

Aviso! Quando você toma um atalho e simplesmente altera a umask em /etc/login.defs para 002 (ou 0002 ) em vez de 022 (ou 0022 ), esteja ciente que todos os arquivos criados por todos os usuários serão, por padrão, agora graváveis por todos os outros usuários no mesmo grupo. Este é um risco de segurança , então é quase certo que isso não é o que você quer.

Uma das razões para a introdução do sistema UPG foi que ele permite que os administradores configurem umask de 002 (ou 0002 ) em vez de 022 (ou 0022 ) para facilitar facilmente o bit setgid para o trabalho colaborativo em projetos sem o risco de segurança descrito.

Até onde eu sei, o OpenSUSE não oferece uma maneira de ativar o UPG durante a instalação ou o YaST e a única maneira de usar o UPG é usar a linha de comando para criar contas de usuário, depois de fazer a alteração necessária em /etc/login.defs : Altere para ter USERGROUPS_ENAB yes . Há uma armadilha aqui. O UPG só funciona corretamente se o ID do usuário e o id do grupo forem idênticos. Se você fizer essa mudança em um sistema em execução, primeiro terá que alterar os IDs dos grupos existentes, o que envolve reatribuir os grupos a todos os arquivos com esses grupos e, no contexto de LDAP, NFS e NIS, isso pode ser um pouco peludo.

Aqui estão algumas leituras adicionais sobre esse tópico, que achei úteis quando eu era novo no tópico de setgid vs. umask e UPGs:

• link
• link

Answer 3

A maioria dos sistemas unix tem um 002 umask, ou seja, apenas o usuário pode gravar arquivos por padrão.

Ter um 022 umask pode ser útil em sistemas em que cada usuário está em seus próprios grupos primários. No entanto, esta umask é repleta de perigos. Isso leva a muitos problemas de suporte com .ssh diretórios que podem ser gravados em grupo e, portanto, ignorados pelo daemon SSH. Isso faz com que arquivos privados sejam vazados porque acabaram pertencendo a um grupo compartilhado. Muitos arquivos acabam pertencendo ao grupo errado, então tê-los em grupo por padrão não é uma boa idéia.

Os diretórios Umask e setgid eram um pouco problemáticos nos dias em que essa era a única maneira de facilitar o compartilhamento de arquivos entre usuários. Atualmente, as ACLs podem fazer um trabalho muito melhor:

• Os bits de permissão estão associados a um grupo específico (em vez de ter configurações separadas para um conjunto de permissões de grupo e a escolha de um grupo ao qual essas permissões se aplicam).
• As permissões dos arquivos não precisam depender de uma configuração do usuário que os usuários podem substituir, elas dependem apenas das permissões no diretório.
• Os arquivos podem ter permissões definidas para mais de um grupo.
• Os arquivos podem ser compartilhados entre usuários que não formam um grupo.

O Umask é obsoleto, use as ACLs.

    

Answer 4

Uma diferença entre, e. RHEL e (open) SuSE é que o RHEL segue os User Private Group scheme no qual o grupo primário de cada usuário é um grupo privado com o mesmo nome que o nome de usuário.

(open) SuSE define o grupo privado de todos os usuários para "usuários" se não me engano.

Naturalmente, uma umask que permite que membros do grupo de um usuário leiam todos os arquivos não é segura se outros usuários forem membros desse grupo. É por isso que o umask padrão é diferente entre (aberto) SuSE e RHEL e outros.

Certifique-se de verificar as implicações de segurança antes de alterar apenas o umask do sistema!