☰

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

tag-icon • tag-icon shell-script files permissions scripting
Como testar de forma não invasiva o acesso de gravação a um arquivo?

Em um script de shell, como posso facilmente ede forma não invasivatestar 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 muito complexo e talvez frágil, embora não tenha certeza de quanto a saída estatística difere entre as implementações e o tempo.

Eu poderia anexar ao final do arquivo e ver se dá certo, mas isso é potencialmente perigoso, por dois motivos que consigo imaginar:

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

Responder1

Basta usar o wsinalizador - dotestutilitário:

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

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

Responder2

Outra abordagem:

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

Isso tentará abrir o arquivo para anexar e, se tiver sucesso, corrernenhum comando(ou seja,execute um comando nulo) com saída para o arquivo. 

Cuidado, pois isso criará um arquivo vazio se ele não existir.

O -woperador do testcomando pode simplesmente fazer um stat e tentar descobrir se parece que você deveria ter acesso. Minha alternativa (acima) é mais confiável que a testabordagem em algumas condições especiais, porque força a verificação de acesso a ser feita pelo kernel e não pelo 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 statpode retornar um valor de modo que é enganoso.
  • se o arquivo estiver em um sistema de arquivos montado somente leitura.
  • se o arquivo tiver uma ACL e o modo fizer parecer que você deveria ter acesso, mas a ACL negar ou vice-versa.
  • se alguma estrutura de segurança (AppArmor, SELinux,…) negar acesso ao arquivo.

Responder3

G-man está certo: [ -w ]não vousemprediga a verdade. Aqui para lidar com arquivos inexistentes ePermissão negadamensagem do shell:

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

Atualizar: Parece assustador, não é? Bem, é. Hmm... como dizer... NÃO USE ISTO, a menos que você saiba perfeitamente que está nas condições necessárias para funcionar conforme o esperado. Veja o comentário de Stephane.

O que concluir, então? Mesmo que [ -w ]não diga a verdade, é o único comando que épretendidopara fazer o trabalho. Se isso não acontecer, vamos culpar, escrever relatórios de bugs e isso funcionará no futuro. É melhor verificar as condições de funcionamento e uso [ -w ]; escreva código especial para casos especiais. As soluções alternativas têm suas próprias condições.

[ -w /path/to/file ]

é o melhora priori.

informação relacionada