Desvantagens de umask 077?
Quais são os contras de ter um umask restritivo de 077? Muitas distros (acredito que todas, exceto Red Hat?) Têm um umask padrão de 022, configurado em/etc/profile. Isso parece muito inseguro para um sistema não desktop, que vários usuários estão acessando, e a segurança é uma preocupação.
Em uma nota relacionada, no Ubuntu, os diretórios pessoais dos usuários também são criados com 755 permissões, e o instalador afirma que isso é para facilitar o compartilhamento de arquivos pelos usuários. Supondo que os usuários se sintam confortáveis em definir permissões manualmente para compartilhar arquivos, isso não é um problema.
Que outras desvantagens existem?
022 torna as coisas convenientes. 077 torna as coisas menos convenientes, mas dependendo das circunstâncias e do perfil de uso, pode não ser menos conveniente do que ter que usar Sudo.
Eu diria que, como Sudo, o benefício de segurança real e mensurável que você ganha com isso é insignificante em comparação com o nível de dor que você inflige a si mesmo e aos seus usuários. Como consultor, fui desprezado por minhas opiniões sobre Sudo e desafiado a quebrar várias configurações de Sudo, e ainda não demorei mais de 15 segundos para fazê-lo. Sua chamada.
Saber sobre umask é bom, mas é apenas um único Corn Flake no "café da manhã completo". Talvez você devesse se perguntar "Antes de mexer com as configurações padrão, a consistência das quais precisará ser mantida nas instalações e que precisarão ser documentadas e justificadas para pessoas que não são estúpidas, o que isso vai comprar mim?"
Umask também é um bash embutido que pode ser configurado por usuários individuais em seus arquivos de inicialização do Shell (~/.bash*), então você realmente não é capaz de aplicar facilmente o umask. É apenas um padrão. Em outras palavras, não está comprando muito.
A desvantagem mais óbvia é quando você começa a criar arquivos/diretórios em um diretório compartilhado, esperando que outros usuários os acessem.
Obviamente, é apenas uma questão de não esquecer de definir o umask correto antes de fazer coisas que precisam ser compartilhadas por todos os usuários.
Outra advertência (que não é realmente uma desvantagem, uma vez que você esteja ciente disso) é quando você começa a fazer coisas Sudo, como instalar programas locais, Ruby gems, python ovos (obviamente não gerencia pacotes de SO), criação de arquivos de configuração e assim por diante.
Você terá problemas porque o umask é herdado pela sessão do Sudo, portanto, apenas o root poderá acessar os arquivos/diretórios que você criar. Sudo pode ser configurado para definir automaticamente o umask da maneira que você quiser: esta questão é abordada em superuser.com .
Umask não seria apropriado se você estivesse tentando controlar o que outros usuários podem ver uns dos outros. No entanto, se você tem e trabalha com vários arquivos que são sensíveis ao ponto de pedir permissão para acessá-los é menos incômodo/arriscado do que apenas permitir que as pessoas vejam o que querem, então um umask de 077 seria uma boa ideia.
Tenho alguns arquivos confidenciais em um servidor de arquivos que gerencio. Acho que definir um umask restritivo e, em seguida, ter um script periódico, talvez um cron job para definir permissões mais específicas para itens em certas pastas, seria uma solução ideal para mim. Quando eu configurar isso irei postar de volta aqui, e contarei como funcionou.
@ [Os caras atacando o Sudo] Inicie um novo tópico para ele, podem ser necessários vários tópicos próprios e este tópico é sobre umask.
Os aplicativos de terceiros que usam seus próprios sistemas de instalação podem ter suposições internas sobre o umask padrão do sistema.
Como um exemplo prático, após atualizar um banco de dados Oracle 10 em um sistema que tinha o umask definido como 077, os aplicativos no mesmo sistema não conseguiram acessar o banco de dados ... porque as bibliotecas essenciais para os clientes do banco de dados e os diretórios das bibliotecas estavam localizados em, agora estavam protegidos para que apenas o usuário Oracle pudesse acessá-los, o que obviamente não era como as coisas deveriam funcionar.
Acontece que o processo de atualização do Oracle não cuidou especificamente de que as permissões das bibliotecas de cliente permitissem que outros usuários as usassem, mas, em vez disso, baseou-se na suposição de que os arquivos adicionados pelo atualizador seriam criados com umask 022 e, portanto, utilizáveis por padrão. Depois de alguns chmod -R a+rX comandos para os diretórios apropriados, tudo estava bem novamente.
Concedido, isso poderia ter sido evitado tratando a conta Oracle como uma conta de sistema especial com umask 022 padrão e restringindo o umask 077 para contas de usuário realmente habilitadas para login ... mas eu acho que isso é uma boa exemplo de como as decisões gerais de "endurecimento" podem ter efeitos colaterais imprevistos.
.rpm e .deb pacotes carregam informações de permissão explícita para qualquer arquivo que eles contenham, então eles geralmente não correm o risco de erros desse tipo.
Isso causará problemas em um servidor; por exemplo, ao ter vários aplicativos em execução como diferentes usuários tentando acessar arquivos de diferentes usuários. Como o Apache lendo arquivos de configuração ou pi-hole lendo dnsmasq.conf. Basta executá-lo em usuários que poderiam se beneficiar dele, como diretórios pessoais individuais, não explicitamente definidos em /etc/profile.
Eu tenho esta linha no meu ~/.zshrc
umask 0077
configurá-lo globalmente provavelmente não é uma boa ideia, mas configurá-lo como o padrão em seu arquivo rc provavelmente não vai prejudicar ou mesmo configurá-lo como o padrão no /etc/skel/.rc Arquivo. todo o sistema irá causar problemas.