
シェルスクリプトで、簡単に非侵襲的に実際にファイルを変更せずに、ファイルへの書き込みアクセスをテストしますか?
の出力を解析することはできますstat
が、これは非常に複雑で、おそらく脆弱です。ただし、実装や時間によって stat 出力がどの程度異なるかはわかりません。
ファイルの末尾に追加して成功するかどうかを確認することもできますが、次の 2 つの理由から、潜在的に危険です。
- ここで追加を削除する必要があり、他のプロセスがファイルに書き込む場合、私の行が最後の行ではなくなるため、これはすぐに重要な問題になります。
- ファイルを読み取るプロセスは、そのファイルの内容に対して任意の要件を持つ可能性があり、そのアプリケーションを壊してしまった可能性があります。
答え1
-w
フラグを使用するだけですtest
ユーティリティ:
[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"
後でファイルに書き込む場合、書き込めない可能性もあることに注意してください。ファイルが移動されたり、権限が変更されたりしている可能性があります。また、-w
書き込み権限を検出したが、他の要因によりファイルが書き込み不可になった。
答え2
別のアプローチ:
if >> /path/to/file
then
echo "writeable"
else
echo "write permission denied"
fi
これはファイルを追加用に開こうとし、成功した場合は 走るコマンドなし(すなわち、ヌルコマンドを実行する) をファイルに出力します。
存在しない場合は空のファイルが作成されるので注意してください。
-w
コマンドのオペレータは、test
単に を実行してstat
、アクセス権があるかどうかを調べようとするかもしれません。私の代替案 (上記) は、test
アクセス チェックをシェルではなくカーネルによって強制的に実行するため、特別な状況では アプローチよりも信頼性が高くなります。たとえば、
- ファイルが非 Unix ファイルシステム上にある場合、特に非 Unix ファイルサーバーからリモートでマウントされている場合、
stat
誤解を招くモード値が返される可能性があります。 - ファイルが読み取り専用でマウントされたファイル システム上にある場合。
- ファイルに ACL があり、モードではアクセスできるように見えるが、ACL ではアクセスが拒否される場合、またはその逆の場合。
- 何らかのセキュリティ フレームワーク (AppArmor、SELinux など) がファイルへのアクセスを拒否した場合。
答え3
G-manは正しい:[ -w ]
しないいつも真実を語る。ここでは存在しないファイルに対処するために許可が拒否されましたシェルからのメッセージ:
( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null &&
echo writable ||
echo not writable
アップデート: 恐ろしそうに見えますね。そうですね。うーん... どう表現したらいいでしょうか... 期待通りに動作するために要求される条件を満たしていることを完全に知っている場合を除いて、これを使用しないでください。Stephane のコメントを参照してください。
では、何を結論づけるのでしょうか?たとえ[ -w ]
真実を語っていなくても、それは意図されました仕事をするために。うまくいかなかったら、私たちはそれを責め、バグレポートを書き、将来はそれが機能するでしょう。それが機能する条件を確認し、[ -w ]
; を使用することをおすすめします。特殊なケースには特別なコードを記述してください。回避策には独自の条件があります。
[ -w /path/to/file ]
一番ですアプリオリ。