同様のマスクを設定しましたが、setfacl -R -d -m m::rw .
ローカルコンピュータで正常に動作します(SSH経由で接続しましたが、ヘッドはありません)。 2 人のユーザーにディレクトリを変更して読み取ることができます。ただし、sshfsを使用してユーザー変更ディレクトリの1つにアクセスすると、有効な設定はrw-ではなくr--に設定されます。手動でシステムにSSHを接続し、ユーザーとしてsudoを使用してファイルを生成すると、これは発生しません。ただし、sshfsを使用してディレクトリを作成できます。
ベストアンサー1
私はしばらくinotifyを使ってややハッキング的な解決策を思いつきました。
inotifywait
fromを使用してファイルが生成されるのを待つシェルスクリプトを作成しましたinotify-tools
。その後、ファイルが作成されたら、コマンドを実行して共有ディレクトリを設定し、共有ディレクトリのすべてのサブディレクトリを見つけてsetfacl
実行可能としてマークします。ディレクトリが実行可能であることを願っています。必要に応じてその部分を除外できます。
スクリプトは次のとおりです。
#!/bin/sh
while inotifywait -qqre create /share; do
setfacl -R -m u:user2:rw /share
for dir in $(tree /share); do
setfacl -m u:user2rwx ${dir}
setfacl -m u:user1:rwx ${dir}
done
done
user2
ユーザーはsshfsを介して共有にアクセスしていますか?
Needinotify-tools
と。代わりに何かをすることtree
もできますが、私の考えにはそれがより簡単になると思います。find
tree
tree
ファイルに外部コマンドのサポートを追加しchmod +x
(他のユーザーのようにファイルを実行可能としてマークすることはできません)、実行可能としてマークしたいファイルを記録し、実行可能ビットを再追加できます。
まだ実稼働環境で徹底的にテストしていませんが(ファイルのアクセス許可/使用権が変更された場合にプログラムが開かない場合は、プログラムがどのように機能するかを確認するために)、私が見たのはかなりうまくいきます。
問題は、現在のシステムからマスキングルールを取得することかもしれませんが、100%確信できません。リモートシステムからrootまたは通常のユーザーとしてsshfsディレクトリのaclを変更できないため、リモートシステムでマスク権限を変更できません。