Por que 666 são as permissões de criação de arquivo padrão?

Question

Como descobri, ao usar umask, as permissões mais altas que você pode dar aos arquivos são 666. O que é feito por umask 0000 . Isso é por causa das permissões de criação de arquivo padrão, que parecem ser 666 em todos os sistemas que eu conheço.

Eu sei que para arquivos precisamos de direitos executáveis para mostrar seu conteúdo.
 Mas por que limitamos as permissões de criação de arquivos padrão em 666?

    

Answer 1

Tanto quanto eu posso dizer, isso é embutido em utilitários padrão. Eu strace d ambos touch criando um novo arquivo e mkdir criando um novo diretório.

O touch trace produziu isso:

open("newfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3

enquanto o mkdir trace produziu isto:

mkdir("newdir", 0777)                   = 0

Faltando codificar o processo de criação de arquivos / diretórios em C, não vejo uma maneira de modificar as permissões padrão. Parece-me, no entanto, que não fazer arquivos executáveis por padrão faz sentido: você não quer que nenhum texto aleatório seja acidentalmente interpretado erroneamente como comandos shell.

Atualizar

Para dar um exemplo de como os bits de permissão são codificados nos utilitários padrão. Aqui estão algumas linhas relevantes de dois arquivos no pacote coreutils que contém o código-fonte para touch(1) e mkdir(1) , entre outros:

mkdir.c :

if (specified_mode)
   {   
     struct mode_change *change = mode_compile (specified_mode);
     if (!change)
       error (EXIT_FAILURE, 0, _("invalid mode %s"),
              quote (specified_mode));
     options.mode = mode_adjust (S_IRWXUGO, true, umask_value, change,
                                  &options.mode_bits);
     free (change);
   }   
  else
    options.mode = S_IRWXUGO & ~umask_value;
}   

Em outras palavras, se o modo não for especificado, defina-o como S_IRWXUGO (leia-se: 0777) modificado pelo umask_value .

touch.c é ainda mais claro:

int default_permissions =
  S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH;

Ou seja, conceda permissões de leitura e gravação a todos (leia-se: 0666), o que será modificado pelo processo umask na criação do arquivo, é claro.

Você pode contornar isso apenas programaticamente: ou seja, ao criar arquivos de dentro de um programa em C, onde você faz chamadas do sistema diretamente ou de dentro de um idioma que permite fazer um syscall de baixo nível (consulte exemplo sysopen de Perl sob perldoc -f sysopen ).

    

Answer 2

Primeiro, não há nenhum padrão global, as permissões dependem do aplicativo que cria o arquivo. Por exemplo, este pequeno programa em C criará um arquivo '/ tmp / foo' com permissões 0777 se umask for 0000 (em qualquer caso, as permissões serão 0777 & umask):

int main() 
{
   creat("/tmp/foo", 0777);
   return 0;
}

Dito isso, muitos aplicativos criam arquivos com permissões de 0666. Isso tem dois motivos:

1. Segurança: você não quer que nenhum arquivo arbitrário seja executável.
2. Conveniência: a maioria dos arquivos não precisa ser executável. É mais fácil definir o bit executável em alguns arquivos selecionados do que desativá-lo na enorme quantidade de outros arquivos. Claro, umask 0133 resolveria isso, mas nada é ganho e você não pode deixar os programas criarem arquivos executáveis, mesmo se você quiser.