アプリケーションが700
権限のあるファイルを書き込んでいることを考慮すると、このグループはファイルを読み取ることができません。これらのファイルを読み取るための特別なバックアップユーザーアカウントが必要です。
ACL
chmod
マスクが変更され、所有者や他のグループ以外のユーザーにはまだ権限がないため、まったく役に立たないようです。
- 正規再帰
chmod
?特に、非常に大きなファイルセットでハキッシュとリソースの無駄が発生します。 - このために(sudo経由)ルートを使用しますか?安全ではありません。細かい制御はありません。リモートシステム(NASなど)から起動されたrsyncには適していません。
- これらのファイルを作成したアプリケーションと同じユーザーを使用します。つまり、バックアップに所有者ユーザーを使用します。バックアップユーザーとしてはまだハッキーで人気がありません。読み取りアクセスのみが可能で、そのディレクトリに対してのみ可能です。。これは、外部から開始された rsync の場合に特に重要です。
- ? などの方法を使用して
bindfs
特定のディレクトリを別のディレクトリにマウントすると、重大なパフォーマンスが低下し、これらの単純な権限関連の操作には適していません。
Linuxでは、管理者がファイルに対するアプリケーションに許可されている最小限の権限を指定することを許可していないのはなぜですか?最大権限はマスクを使用して制限できますが、透過的に適用または追加することはできません。奇妙に見えます。
解決策はありますか?
答え1
同様の状況で私はこのchmod
アプローチをとったが、起動時に実行し、inotifywait
。以下は、私が実際に使用しているコードの簡単なバージョンです。また、所有権/グループ化関係を処理し、変更やエラーを記録します。
#!/bin/bash
inotifywait --monitor --recursive --event create,attrib --format '%w%f' "$@" |
while IFS= read -r item
do
# Avoid looping when we apply the fix-up chmod
perm=$(stat -c %A "$item")
if [[ -d "$item" ]] && [[ ! "$perm" =~ dr.xr.xr-x ]]
then
# Directory with wrong permissions
printf 'dir\t%s\n' "$item"
chmod ug+rx,o=rx "$item"
fi
if [[ ! -d "$item" ]] && [[ ! "$perm" =~ -r..r..r.. ]]
then
# Item (not a directory) with wrong permissions
printf 'other\t%s\n' "$item"
chmod ug+rw,o-w,o+r "$item"
fi
done
コードは改行文字を含むファイル名を処理できないことがわかりますが、chmod
これはファイルが作成されたときまたはそのプロパティが変更されたときにのみトリガーされるツールによって調整されます。大規模な通常のデータセットに適しています。
すべての権限を無条件に変更する非定期的なプロセスでこれを補完できます。この例では、ユーザー/グループ権限が少なくとも読み取り(またはディレクトリの場合は実行)であり、他のすべての人は同じ権限を持ちますが、書き込み権限はないことを確認します。
find /path/to/base -type d -exec chmod ug+rx,o=rx {} \; -o -exec chmod ug+rw,o-w,o+r {} \;
今日の解決策を書いている場合は、検討してみることもできます。incron
ループの代わりに