Por que umask não altera as permissões de execução nos arquivos? [duplicado]

Question

Se eu alterar o umask para 0000 , esperaria que um arquivo de texto fosse criado com rwxrwxrwx de permissões (com base no meu entendimento do umask, descrito na pergunta "possível duplicado" No entanto, quando tento isto, obtenho o seguinte

$ umask 0000
$ touch /tmp/new.txt
$ ls -ld /tmp/new.txt 
-rw-rw-rw-  1 alanstorm  wheel  0 Jun  2 10:52 /tmp/new.txt

Ou seja, a permissão de execução é omitida e acabo com rw-rw-rw- para arquivos (os diretórios são rwxrwxrwx ). Eu tentei isso na minha máquina OS X local, uma velha máquina BSD que eu tenho em um host compartilhado, e um servidor linux rodando no linode.

Por que isso? É meu entendimento que umask é o árbitro final de permissões - a minha compreensão disso é incorreta? Se sim, o que mais influencia as permissões padrão dos arquivos em um sistema unix?

    

Answer 1

umask é subtrativo, não prescritivo: bits de permissão definidos em umask são removidos por padrão dos modos especificados por programas, mas umask não pode adicionar bits de permissão. touch especifica o modo 666 por padrão (o link é para a implementação do GNU, mas outros se comportam da mesma maneira, isto é especificado por POSIX ), então o arquivo resultante termina com o mascarado pelo atual umask : no seu caso, como umask não mascara nada, o resultado é 666.

O modo de um arquivo ou diretório é geralmente especificado pelo programa que o cria; a maioria das chamadas de sistema envolvidas tem um modo ( por exemplo open(2) , creat(2) , mkdir(2) todos têm um parâmetro mode, mas fopen(2) não usa o modo 666). A menos que o diretório pai especifique uma ACL padrão, a umask do processo no momento da chamada é usada para mascarar o modo especificado (bit a bit mode & ~umask ; efetivamente isso subtrai cada conjunto de permissões em umask do modo), portanto o umask só pode reduzir um modo, não pode aumentá-lo. Se o diretório pai especificar uma ACL padrão, isso é usado em vez do umask: as permissões de arquivo resultantes são a interseção do modo especificado pelo programa de criação e o especificado pela ACL padrão.

POSIX especifica que o modo padrão deve ser 666 para arquivos, 777 para diretórios ; mas isso é apenas um padrão documentação ( ie , ao ler POSIX, se um programa ou função não especificar um modo de arquivo ou diretório, o padrão se aplica), e é não imposta pelo sistema. De um modo geral, isto significa que as ferramentas compatíveis com POSIX especificam o modo 666 ao criar um arquivo, e o modo 777 ao criar um diretório, e o umask é subtraído daquele; mas o sistema não pode impor isso, porque há muitos motivos legítimos para usar outros modos e / ou ignorar umask:

• compiladores que criam um executável tentam produzir um arquivo com o conjunto de bits executáveis (eles aplicam umask embora);
• chmod(1) obviamente especifica o modo dependendo de seus parâmetros, e ignora umask quando "quem" é especificado ou o modo é totalmente especificado (por isso, chmod o+x ignora umask, assim como chmod 777 , mas chmod +w aplica umask);
• ferramentas que preservam as permissões aplicam o modo apropriado e ignoram umask: por exemplo cp -p , tar -p ;
• ferramentas que levam um parâmetro especificando totalmente o modo também ignoram umask: install --mode , mknod -m ...

Portanto, você deve pensar em umask como especificando os bits de permissão que você não deseja ver definidos por padrão, mas esteja ciente de que isso é apenas uma solicitação. Você não pode usá-lo para especificar os bits de permissão que deseja ver definidos, apenas aqueles que você deseja ver não definidos. Além disso, qualquer processo pode alterar sua umask de qualquer maneira, usando a umask(2) chamada do sistema! A chamada do sistema umask(2) também é a única forma definida pelo POSIX para um processo descobrir sua umask atual (herdada de seu pai). No Linux, começando com o kernel 4.7, você pode ver umask atual de um processo por procurando por Umask em /proc/${pid}/status .

(Para completar, eu mencionarei que o comportamento em relação a setuid , setgid e sticky bits é dependente do sistema, e sistemas de arquivos remotos como o NFS podem adicionar suas próprias reviravoltas.)

    

Answer 2

A fórmula para calcular sua permissão de arquivo:

default_mode & ~umask

( Leia a descrição de O_CREAT flag )

Também especificado por POSIX , o modo padrão para o arquivo é S_IROTH | S_IWOTH | S_IRGRP | S_IWGRP | S_IRUSR | S_IWUSR ou 666 , o modo padrão para o diretório é S_IRWXU | S_IRWXG | S_IRWXO ou 777 se não foi especificado pelo aplicativo.

Desde quando os bits de execução no modo padrão do arquivo são 0 , execute bit a bit E & com 0 é sempre 0 .

É por isso que, qualquer que seja o valor de umask , seus arquivos recém-criados terão bits de execução desligados se seu aplicativo não especificar os bits de execução.

    

Answer 3

A descrição acima é muito boa. Ele fornece uma descrição clara de umask e permissões. Para ser mais prático, se você quiser ver, quais são as permissões fornecidas pelo "toque" do

"toque em strace /tmp/new.txt"

observe a chamada do sistema usada pelo toque para criar "novo.txt"

por ex. o / p de "strace touch /tmp/new.txt" (... - > algum conteúdo)

...

open ("/ tmp / new.txt", O_WRONLY | O_CREAT | O_NOCTTY | O_NONBLOCO, 0666) = 3

...

para referência strace