Desvantagens do umask 077?

Quais são os contras, por ter uma umask restritiva de 077? Muitas distribuições (acredito que todas, exceto a Red Hat?) Têm uma umask padrão de 022, configurada em / etc / profile. Isso parece inseguro demais para um sistema não desktop, que vários usuários estão acessando, e a segurança é preocupante.

Em uma observação relacionada, no Ubuntu, os diretórios pessoais dos usuários também são criados com permissões 755, e o instalador afirma que isso é para facilitar o compartilhamento de arquivos pelos usuários. Supondo que os usuários estejam 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, assim sudo, o benefício real e mensurável de segurança que você obtém disso é insignificante em comparação com o nível de dor que você inflige a si e aos seus usuários. Como consultor, fui desprezado por minhas opiniões sudoe desafiado a interromper várias sudoconfigurações, e ainda preciso levar mais de 15 segundos para fazê-lo. Sua chamada.

Saber umaské bom, mas é apenas um único Floco de Milho no "café da manhã completo". Talvez você deva estar se perguntando "Antes de eu mexer nas configurações padrão, cuja consistência precisará ser mantida nas instalações e que precisará ser documentada e justificada para pessoas que não são idiotas, o que isso vai comprar? mim?"

O Umask também é um bash embutido, que pode ser definido por usuários individuais em seus arquivos de inicialização do shell ( ~/.bash*), para que você não consiga realmente 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 a umask correta antes de fazer coisas que precisam ser compartilhadas por todos os usuários.

Outra ressalva (que não é realmente uma desvantagem, quando você está ciente disso) é quando você começa a fazer coisas com o sudo, como instalar programas locais, ruby ​​gems, ovos python (não é o sistema operacional que gerencia pacotes obviamente), criar arquivos de configuração e assim por diante.

Você terá problemas porque a umask é herdada pela sessão sudo, portanto, apenas o root poderá acessar os arquivos / diretórios criados por você. O sudo pode ser configurado para definir automaticamente o umask da maneira que você deseja: esta questão é abordada no superuser.com .

O Umask não seria apropriado se você estivesse tentando controlar o que os outros usuários podem ver um do outro. No entanto, se você possui e trabalha com vários arquivos sensíveis ao ponto de ser solicitada permissão para acessá-los, isso é menos incômodo / arriscado do que deixar as pessoas verem o que quiserem, seria uma boa idéia uma umask 077.

Eu tenho alguns arquivos confidenciais em um servidor de arquivos que eu gerencio. Eu acho que definir uma umask restritiva e depois ter um script periódico, talvez um trabalho cron para definir permissões mais específicas para itens em determinadas pastas, seria uma solução ideal para mim. Quando eu configurar isso, postarei de volta aqui e informarei como funcionou.

@ [The guys bashing sudo] Inicie um novo tópico para ele, ele pode levar vários tópicos e esse tópico é sobre umask.

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 exemplo prático, após a atualização de um banco de dados Oracle 10 em um sistema com o umask definido como 077, os aplicativos no mesmo sistema falharam ao 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 oracleusuário pudesse acessá-los, o que obviamente não era como as coisas deveriam funcionar.

Acontece que o processo do atualizador Oracle não teve o cuidado específico de que as permissões das bibliotecas clientes permitissem a outros usuários, mas sim a 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+rXcomandos criteriosos para os diretórios apropriados, tudo estava bem novamente.

Concedido, isso poderia ter sido evitado tratando a oracleconta como uma conta especial do sistema com o padrão umask 022 e restringindo o umask 077 a apenas contas de usuário realmente capazes de fazer login ... mas acho que este é um bom exemplo de como "proteger" "decisões podem ter efeitos colaterais imprevistos.

.rpme os .debpacotes carregam informações explícitas de permissão para todos os arquivos que eles contêm; portanto, eles geralmente não correm o risco de erros desse tipo.

Eu tenho essa linha na minha ~/.zshrc

umask 0077

defini-lo globalmente provavelmente não é uma boa ideia, mas defini-lo como padrão no seu arquivo rc provavelmente não vai prejudicar ou até defini-lo como o padrão no /etc/skel/.rcarquivo. todo o sistema causará problemas.

Isso causará problemas em um servidor; por exemplo, ao ter vários aplicativos em execução como usuários diferentes tentando acessar arquivos de usuários diferentes. Como o apache lendo arquivos de configuração ou pi-hole reading dnsmasq.conf. Basta executá-lo em usuários que poderiam se beneficiar dele, como diretórios pessoais individuais, não explicitamente definidos /etc/profile.