Maneira portátil de consultar umask para novas permissões de arquivo?

Question

Estou acompanhando um tópico da OSS-Security chamado Risco de segurança do vim swap arquivos . Parece que o Vim e o Emacs capturaram um CVE porque os editores criaram arquivos temporários no lugar errado com muitas permissões de arquivos.

Eu sei que o Posix tem uma função umask para definir a máscara, mas não realmente ver uma função para consultá-lo. Eu também estou ciente de que alguns shells suportam UMASK , mas eu não vi isso mencionado nas páginas do IEEE que visitei. (Talvez eu tenha perdido; veja também Como verificar umask para todos os usuários no Linux? ).

Como os programas podem consultar o valor de umask de maneira portátil?

    

Answer 1

O shell umask incorporado sem argumento imprime o valor do atual umask .

A chamada do sistema umask() imprime o valor do umask anterior, então você pode fazer:

umask = umask(0777);
umask(umask);

(ou umask(umask = umask(0777)) como idioma comum).

Isso é o que o umask shell faz. Observe que em programas multi-threaded, esse processo de dois estágios pode ser problemático se outro thread chamar umask() ao mesmo tempo. Mas geralmente, os programas geralmente fazem isso na inicialização para descobrir o umask() que tinham inicialmente.

Para obter o umask de outro processo, nas versões recentes do Linux ( 4.7 ou superior ), você pode fazer:

sed -ne 's/^Umask:[[:blank:]]*//p' < "/proc/$pid/status"

Observe que a consideração de segurança mencionada no link que você postou não é sobre permissões¹, mas sobre o arquivo swp que contém o conteúdo do arquivo editado, mas com uma extensão diferente ( .swp em vez de .php ). E se o servidor da Web não estiver configurado para não fornecer arquivos ocultos, o arquivo .swp será exibido. E como não é um arquivo php, o conteúdo bruto (o código-fonte do php, ao contrário do resultado da interpretação) será exibido, potencialmente vazando informações confidenciais, como senhas de banco de dados.

É por isso que os servidores da web geralmente são configurados não para exibir arquivos ou arquivos ocultos que terminam em ~ ou seguem padrões comuns de backup de editor ou nome de arquivo temporário.

Mesmo que vim honrasse o umask e você tivesse um umask muito restritivo como 077 , ainda não ajudaria no caso comum (pense em implantações de servidores da Web hospedados na nuvem) onde há apenas um usuário envolvido e o arquivo .swp é criado com o mesmo proprietário como o arquivo que está sendo editado.

Uma solução melhor é informar vim para criar o arquivo swp em um diretório que você tenha acesso somente com a opção directory vim . Veja

:h swap-file

dentro de vim para detalhes.

Ou, melhor ainda, não edite os arquivos diretamente na área servida pelo servidor da Web, mas em uma cópia separada, como um git ou outra cópia de trabalho em que você possa se interessar, rastreie as alterações e envie a nova versão para o servidor web real, uma vez que você esteja satisfeito com ele.

^{¹ Estritamente falando, há um problema em potencial com permissões também. vim usará as mesmas permissões que o arquivo editado para o arquivo .swp (umask não está envolvida aqui), mas não replicará as ACLs, se houver. Ter um usuário ACL em um arquivo significa que o campo de permissão retornado por stat() será visto como tendo permissão extra para o grupo (por causa da máscara ACL) e o arquivo .swp em esses casos podem ter permissões muito amplas para o grupo.}