Altere a propriedade do arquivo durante a operação de gravação

Question

Por padrão, o umask é 0022:

usera@cmp$ touch somefile; ls -l
total 0
-rw-r--r-- 1 usera usera 0 2009-09-22 22:30 somefile

O diretório /home/shared/ é destinado a arquivos compartilhados e deve ser de propriedade de root e shared group. Os arquivos criados aqui por user n (qualquer usuário) pertencem automaticamente ao grupo shared . Existe um cron-job que cuida de alterar o usuário e o grupo proprietário (de qualquer arquivo movido) uma vez por dia:

usera@cmp$ cat /etc/cron.daily/sharedscript

#!/bin/bash

chown -R root:shared /home/shared/
chmod -R 770 /home/shared/

Eu estava escrevendo um arquivo muito grande para o diretório compartilhado. Eu tinha ( usera ) como usuário proprietário e o shared group como proprietário do grupo. Durante a operação de gravação, a tarefa cron foi executada e ainda não tive problemas para concluir o processo de gravação.

Você vê. Eu pensei que isso aconteceria:

1. Estou escrevendo o arquivo. As permissões de arquivo e os dados de propriedade do arquivo se parecem com isto: -rw-r--r-- usera shared
2. O cron job entra em ação! A linha chown é processada e agora o arquivo é de propriedade do usuário root e do grupo shared .
3. Como o grupo proprietário só tem acesso de leitura ao arquivo, recebo um erro de gravação de arquivo! Estrondo! Fim da história.

Por que a operação teve sucesso? Um link para algum tipo de documentação de referência para apoiar o motivo seria muito bem-vindo (como eu poderia usá-lo para estudar mais detalhes).

    

Answer 1

Afaik, POSIX 1003.1 requer apenas fopen para retornar um erro [EACCES] em privilégios insuficientes. Operações subseqüentes como fputc podem retornar um [EBADF] erro de descritor de arquivo incorreto, mas não acredito que isso signifique cobrir as alterações de permissão enquanto o arquivo estiver aberto.

Anos atrás, eu trabalhava em uma empresa onde tínhamos nossos servidores AIX configurados para que eles usassem essa propriedade para tornar os arquivos de log mais seguros. Quando um serviço é iniciado, o root toca em /var/log/service.log, depois o chupa para serveruser: servergroup, su - inicia o serviço (ele abre o arquivo no modo append) e, em seguida, coloca o arquivo de volta na raiz. Consequentemente, o serviço poderia acrescentar ao seu próprio arquivo de log, mas não excluir ou substituí-lo, portanto, se um invasor conseguisse comprometer o serviço, ele não poderia adulterar as entradas de log anteriores.

Um truque semelhante pode ser usado para arquivos temporários: abra o arquivo e remova-o. A entrada de diretório desapareceu e o arquivo é invisível, mas como o identificador de arquivo ainda está aberto, o inode ainda está lá. Depois que você fechar o arquivo, a contagem de links será zerada e o sistema operacional recuperará o espaço em disco.

    

Answer 2

Eu acho que a razão é que quando o cron entra em ação, você ainda tem um identificador válido para o arquivo, então você pode usá-lo normalmente. Em outras palavras, o sistema verifica seus direitos apenas quando você tenta abri-lo, não em todas as operações de arquivos.

    

Answer 3

Como Joril disse, as permissões são relevantes quando o arquivo é aberto; eles não são verificados depois disso.

Lembre-se de que você pode criar um arquivo para gravação com 400 (ou 444 ou 000) permissões no arquivo. Você precisa de permissão para criar o arquivo no diretório, é claro, mas pode ter acesso de gravação a um arquivo que ninguém (exceto o root) pode modificar.

Observe também que o grupo pode ser definido por padrão, definindo o bit SGID no diretório holding:

chmod g+s /home/shared

Todos os arquivos criados no diretório pertencerão ao grupo que possui /home/shared até que o grupo seja alterado. No MacOS X, o sistema se comporta como se o bit SGID fosse definido em todos os diretórios - quando um arquivo é copiado para um diretório, o grupo é definido para o grupo que possui o diretório.