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

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 é devido às permissões de criação de arquivo padrão, que parecem 666 em todos os sistemas que eu conheço.

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 arquivo padrão em 666?

Até onde eu sei, isso é codificado em utilitários padrão. I straced tanto a touchcriação de um novo arquivo e uma mkdircriação de um novo diretório.

O touchrastreio produziu isso:

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

enquanto o mkdirrastreio produziu isso:

mkdir("newdir", 0777)                   = 0

Além de 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 tornar os arquivos executáveis ​​por padrão faz sentido: você não deseja que nenhum texto aleatório seja acidentalmente mal interpretado como comandos do 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 coreutilspacote que contém o código-fonte para ambos 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, configure-o para 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), que serão modificados pelo processo umaskde criação do arquivo, é claro.

Você pode contornar isso programaticamente apenas: por exemplo, ao criar arquivos a partir de um programa C, em que você faz chamadas do sistema diretamente ou de um idioma que permite fazer uma chamada syscall de baixo nível (veja, por exemplo, Perl sysopenem perldoc -f sysopen)

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

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

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

1. Segurança: você não deseja 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 poucos arquivos do que desmarcá-lo na enorme quantidade de outros arquivos. Obviamente, o umask 0133 resolveria isso, mas nada é ganho e você não pode permitir que os programas criem arquivos executáveis, mesmo que você queira.