Como testar de forma não invasiva o acesso de gravação a um arquivo?

Question

Em um script de shell, como eu facilmente e não invasivamente testo o acesso de gravação a um arquivo sem realmente tentar modificar o arquivo?

Eu poderia analisar a saída de stat , mas isso parece realmente complexo e talvez frágil, embora eu não saiba ao certo quanto a saída de estatísticas difere entre as implementações e o tempo.

Eu poderia acrescentar ao final do arquivo e ver se isso é bem-sucedido, mas isso é potencialmente perigoso, por duas razões que posso pensar:

1. Agora preciso remover a adição e, caso algum outro processo grave no arquivo, isso se torna imediatamente não trivial, pois minha linha não é mais a última.
2. Qualquer processo de leitura do arquivo pode ter requisitos arbitrários sobre o conteúdo desse arquivo, e eu posso ter quebrado esse aplicativo.

Answer 1

Basta usar a bandeira - w da test utillity:

[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"

Observe que, se você for gravar no arquivo mais tarde, ainda será possível que não seja possível gravar nele. O arquivo pode ter sido movido, as permissões podem ter sido alteradas, etc. Também pode acontecer que -w detecta permissões de gravação mas algum outro fator intervém para tornar o arquivo não gravável .

    

Answer 2

Outra abordagem:

if >> /path/to/file
then
    echo "writeable"
else
    echo "write permission denied"
fi

Isso tentará abrir o arquivo para anexar e, se isso for bem-sucedido, executa nenhum comando (isto é, executa um comando nulo ) com saída para o arquivo.

Tenha em atenção que isto cria um ficheiro vazio, se não existir.

O operador -w do comando test pode apenas fazer um stat e, em seguida, tente descobrir se parece que você deve ter acesso. Minha alternativa (acima) é mais confiável do que a abordagem test em algumas condições especiais, porque força a verificação de acesso a ser feita pelo kernel ao invés do shell. Por exemplo,

• se o arquivo estiver em um sistema de arquivos não-Unix - especialmente se for montado remotamente a partir de um servidor de arquivos não-Unix - porque stat pode retornar um valor de modo enganoso.
• se o arquivo estiver em um sistema de arquivos montado somente para leitura.
• se o arquivo tiver uma ACL e o modo parecer que você deve ter acesso, mas o ACL nega, ou vice-versa.
• se alguma estrutura de segurança (AppArmor, SELinux,…) negar acesso ao arquivo.

Answer 3

G-man está certo: [ -w ] não irá sempre dizer a verdade. Aqui para lidar com arquivos não existentes e a mensagem Permission denied do shell:

( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null && 
  echo writable || 
  echo not writable

Atualização : parece assustador, não é? Bem, é isso. Hmm ... como expressar isso ... NÃO USE ISSO, a menos que você saiba perfeitamente que está nas condições que ele solicita para funcionar como esperado. Veja o comentário de Stephane.

O que concluir, então? Mesmo se [ -w ] não disser a verdade, é o comando que é pretendido para fazer o trabalho. Se isso não acontecer, bem, vamos culpar, escrever relatórios de bugs e isso funcionará no futuro. Melhor verificar as condições sob as quais ele funciona e usar [ -w ] ; escreva código especial para casos especiais. Soluções alternativas têm suas próprias condições.

[ -w /path/to/file ]

é o melhor a priori .