web-dev-qa-db-ja.com

ファイルへの書き込みアクセスを非侵襲的にテストする方法は？

シェルスクリプトで、実際にファイルを変更せずに、ファイルへの書き込みアクセスを非侵襲的簡単にテストするにはどうすればよいですか？

statの出力を解析することもできましたが、実装と時間によってstat出力がどれだけ異なるかはわかりませんが、それは本当に複雑で、おそらく壊れやすいようです。

ファイルの最後に追加して、それが成功するかどうかを確認することもできますが、これは潜在的に危険です。

  1. ここで追加を削除する必要があります。他のプロセスがファイルに書き込む場合、私の行は最後の行ではないため、これはすぐに重要になります。
  2. ファイルを読み取るプロセスには、そのファイルの内容に対して任意の要件がある可能性があり、私はそのアプリケーションを壊しただけかもしれません。
shell-scriptfilespermissionsscripting
22
user50849

w ユーティリティの-testフラグを使用するだけです。

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

後でファイルに書き込む場合でも、ファイルに書き込めない可能性があることに注意してください。ファイルが移動した、アクセス許可が変更された、などの可能性があります。 -wは書き込み権限を検出しますが、他の要因が介入してファイルを書き込み不可にします 。

29
chaos

別のアプローチ：

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

これは追加のためにファイルを開こうとし、成功した場合はrun no command（つまり、nullコマンドを実行します）。ファイルに出力します。

存在しない場合は、空のファイルが作成されることに注意してください。

testコマンドの-w演算子は、単にstatを実行して、アクセス権があるように見えるかどうかを判断する場合があります。私の代替案（上記）は、アクセスチェックをシェルではなくカーネルが強制的に実行するため、一部の特殊な状況ではtestアプローチよりも信頼性が高くなります。例えば、

  • ファイルが非UNIXファイルシステム上にある場合、特に非UNIXファイルサーバーからリモートでマウントされている場合-statが誤解を招くモード値を返す可能性があるため。
  • ファイルが読み取り専用でマウントされているファイルシステム上にある場合。
  • ファイルにACLがあり、モードによってアクセス権があるはずのように見えるが、ACLはそれを拒否する、またはその逆の場合.
  • 一部のセキュリティフレームワーク（AppArmor、SELinuxなど）がファイルへのアクセスを拒否した場合。
11
G-Man Says 'Reinstate Monica'

G-manは正しい：[ -w ]は常に真実を伝えません。シェルからの存在しないファイルとPermission deniedメッセージに対処するには、次のようにします。

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

更新：恐ろしいですね。そうですね。うーん...どのようにそれを言い表すか...あなたがそれが期待通りに機能するように要求する状態にいることを完全に知らない限り、これを使わないでください。ステファンのコメントを参照してください。

それでは、何を結論付けますか？たとえ [ -w ]は真実を告げるものではありません。それは、意図された仕事をするための1つのコマンドです。うまくいかない場合は、それを非難し、バグレポートを作成します。将来的には機能します。動作する条件を確認し、[ -w ];特別な場合のために特別なコードを書いてください。回避策には独自の条件があります。

[ -w /path/to/file ]

最高ですアプリオリ。

3
Champignac