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

12

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?

Pedro
fonte
Que tipo de sistema? A única umaskque eu conheci sempre foi 0022, criando permissão padrão 644.
manatwork
Não, você não entendeu. O Umask está usando as permissões de arquivo padrão 666 e subtrai seu próprio valor (que é 0022 para o seu sistema). Assim, a maioria das permissões que você pode definir é umask 0000- que ainda limita a permissões de 666. (Mas, aparentemente, pastas usar 777) de arquivo
Peter
Entendi. Agora, esta é uma boa pergunta.
manatwork
2
Você não precisa de permissões executáveis ​​para ver o conteúdo do arquivo. É o caso dos diretórios, e é por isso que os diretórios são criados por padrão com permissões de execução.
Joseph R.
1
Eu acredito [mas precisaria procurar mais para ter certeza] de que isso ocorre por design, para evitar alguns problemas de segurança: sem acesso ao "chmod", você não pode tornar um arquivo executável. umask 0000 cria arquivos com 0666 e diretórios com 0777 [que, por sinal, é bastante uma enorme configuração padrão, segurança sábio!]
Olivier Dulac

Respostas:

10

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)

Joseph R.
fonte
Você está certo, não quero acidentes. Mas não ter como mudar isso, é horrível! Os valores padrão devem ser 777. E precisamos umask filee umask dir. Defina dois valores padrão diferentes e fine. Mas agora não tenho como criar arquivos com permissões permanentes.
31413 Peter
1
@PeterI Bem, mkdir(1)oferece uma -mopção para especificar o modo do diretório no momento da criação. Com os arquivos, no entanto, como a criação do arquivo usa o open(2)syscall, a ferramenta que você usa para criar o arquivo é a responsável por passar os bits de modo opene você não tem opinião sobre o assunto. install(1)por padrão, copia seu arquivo para um novo local e define os bits de execução, mas isso ainda não está acontecendo no momento da criação.
Joseph R.
O que você está dizendo, que touchpor exemplo é responsável por definir os valores certos. Você sabe onde ele armazena os valores? Talvez eles sejam definidos em todo o sistema - para que possamos alterá-los? Porque eu quero me libertar ;) #
22413 Peter Peter
@PeterI Veja a resposta atualizada.
Joseph R.
1
@ PeterI Atualizei a resposta novamente. Você pode fazer o syscall diretamente de C ou de outro idioma como o Perl.
Joseph R.
6

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.
Adaephon
fonte
1
Os arquivos são criados sem o bit x (execute) definido por razões de segurança. A execução inadvertida de arquivos [cw] deveria ser uma "coisa ruim" (tm). O programa chmod permite que você (re) defina os bits de permissão conforme necessário.
ChuckCottrill