作成されたファイルとフォルダーの所有者を強制する

多数のユーザー間で共有されるデータを含むディレクトリがあります。このディレクトリおよびその下にあるものへのアクセスは、問題のユーザーに追加されるディレクトリのグループによって制御されます。そのため、「スティッキグループ」chmod g+sセットのフォルダを作成しました。ディレクトリには、ディレクトリとファイルのツリー構造が含まれます。ファイルの合計量はおそらく数百万です。ファイルはかなり小さくなり、50MBを超えるものは予想していません。

私の問題は、ファイルまたはディレクトリの所有者がまだそれを作成したユーザーであることです。そのため、アクセスグループからそのユーザーを削除する必要がある場合でも、彼のアクセスを完全には削除しません。

そう：

すべてのファイルとサブディレクトリの所有者を同じにするために見逃した他のオプションはありますか？

cronジョブを使用して定期的にディレクトリ全体を閲覧できると思いますが、基本的には1回しか実行されないコマンドに対しては非効率的だと思います。

INotifyを使用した例を見つけましたが、スクリプトを作成する必要があるため、メンテナンスの手間がかかります。

ACLが所有権の強制に役立つかどうかはわかりませんでした。

これを行うよりスマートな方法はありますか？

私が欲しいのは、ユーザーにグループを追加することで共有できるディレクトリを持つことです。このディレクトリで作成されたものはすべて、その親から許可スキームを継承します。私がしようとしているものよりも良い方法があれば、私はすべて耳です。

デフォルトの所有者を「自動的に」設定するには、次のsetuidような動作をするディレクトリが必要ですsetgid。ただし、これはFreeBSDで設定できますが、他のUNIXおよびLinuxシステムでは単に無視されu+sます。ただし、あなたの場合、別の解決策があるかもしれません。

私が欲しいのは、ユーザーにグループを追加することで共有できるディレクトリを持つことです。このディレクトリで作成されたものはすべて、その親から許可スキームを継承します。私がしようとしているものよりも良い方法があれば、私はすべて耳です。

したがって、基本的には、私が見るものから、グループメカニズムを使用してディレクトリへのアクセスを制御する必要があります。ただし、これには、ディレクトリ構造全体のアクセス許可を制限する必要はありません。実際には、ディレクトリ--x実行ビットは必要なものだけです。例を挙げましょう。仮定して...

• group_dirディレクトリへのアクセスを制御するグループはourgroupです。
• ourgroupグループ内のユーザーのみがアクセスできますgroup_dir。
• user1とにuser2属しourgroupます。
• デフォルトのumaskは0022です。

...次の設定を検討してください。

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

^{ここでは、すべてのアイテムが所有者によって作成されたと仮定します。}

さて、このセットアップでは：

• すべてのディレクトリは、の全員が自由に閲覧できますourgroup。グループ内の誰でも、ファイルを作成、移動、削除できますgroup_dir（ただし、より深くはできません）。
• にいない人ourgroupはでブロックさgroup_dirれるため、その下にあるものを操作することはできません。たとえば、user3（のメンバーではないourgroup）読み取りはできませんgroup_dir/user2_submission/README（r--ファイル自体の許可がある場合でも）。

ただし、この場合には少し問題があります。通常のumaskのため、ユーザーが作成したアイテムはグループの他のメンバーが操作できません。これがACLの出番です。デフォルトのアクセス許可を設定することにより、umask値にもかかわらずすべてが正常であることを確認できます。

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

この呼び出しセット：

• rw(x)所有者のデフォルトの許可。
• rw(x)グループのデフォルトの許可。
• 他のユーザーにはデフォルトで許可はありません。他のユーザーはgroup_dirとにかくアクセスできないため、その下にあるユーザーのアクセス許可がどうでもかまわないことに注意してください。

さて、次のようにアイテムを作成するとuser2：

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

このACLを配置したら、以前の構造を再構築することができます。

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

^{ここでも、各アイテムは所有者によって作成されます。}

さらに、ディレクトリを使用しているユーザーにもう少し電力/セキュリティを提供したい場合は、スティッキービットを検討することをお勧めします。これにより、たとえば、user1削除ができなくなりますuser2_submission（彼はに-w-アクセス許可を持っているためgroup_dir）：

$ chmod +t group_dir/

さて、もしuser1削除しようとするuser2のディレクトリ、彼は素敵なを取得しますOperation not permitted。ただし、これによりのディレクトリ構造の変更は防止されgroup_dirますが、その下のファイルとディレクトリには引き続きアクセスできます。

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

考慮すべきもう1つのことは、使用したACLが既定のアクセス許可を設定していることです。そのため、アイテムの所有者は、アイテムに関連付けられている権限を変更できます。たとえば、user2完全に実行できます...

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

...したがって、彼の完全な提出ディレクトリをグループの誰もが利用できなくなります。

ただし、元々rwsはグループ内のすべてのユーザーにフルアクセスを許可するため、これらのユーザーを信頼しており、悪意のある操作が多く発生することはないと想定しています。

これを行うよりスマートな方法があります。set-gidとデフォルト ACLの組み合わせを使用します。明らかに、acl対応のファイルシステムが必要になります。共有したいディレクトリが/var/grpdirあり、グループのメンバーがsharingそれにアクセスできるはずだと仮定しましょう。

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

デフォルトACLは、デフォルトACLを持つディレクトリに作成されたサブディレクトリに継承されます。つまり、で作成されたファイルに/var/grpdirはsharing、ディレクトリのsetgidビットによってグループが設定されます。さらに、特定のユーザーまたはグループでACLを指定しなかったため、デフォルトのACLを継承し、デフォルトのLinuxスタイルの許可をオーバーライドします。これは、すべてのファイルが所有権<user>:sharingと権限で作成されることを意味しますrw-rw----。ディレクトリも同じです。ただし、独自のデフォルトACLが親（/var/grpdir）と同じに設定され、もちろんユーザーとグループに実行可能ビットが設定されます。sharingグループからユーザーを削除すると、そのユーザーはディレクトリにアクセスできなくなります（ユーザーが所有していても、ディレクトリ内のファイルもアクセスできません）。

cronjobで定期的にアクセス許可を修正するのとは異なり、アクセス許可は、新しく作成されたファイルとディレクトリでアトミックに更新されるため、常に同期しています。このソリューションは軽量です。デーモンは不要です。また、アクセス許可を修正する際にIOが急増することはありません。

私はこれを行う良い方法を知りません。技術的に最もクリーンな方法は、それを行うFUSEファイルシステムです。もちろん、まだ誰もやっていなければ、多くの仕事があります。

代替案：

1. sambaを使用します。sambaにはforce userパラメーターがあります。ディレクトリをローカルにエクスポートして、ローカルにマウントできます。アクセスを高速化しませんが、ループバックネットワーキングのみが関係するため、許容される場合があります。

2. FAT32などの非Linuxファイルシステムを使用します。特定のユーザーがマウントするには、これを構成する必要があります。アクセス許可は、親ディレクトリで処理する必要があります。

ファイルが特定のディレクトリに移動されるとファイルの所有者が変更されるように、ファイルの所有権を自動的に変更する方法を聞いたことはありません。最も近いのはスティッキービットですが、グループの所有権では不十分であり、実際のユーザーの所有権を変更する必要があることを示しているようです。

その場合、Pandyaが述べたように、最善の策はchown -Rフラグを使用したcronジョブだと思います。cronに配置して、1分ごとまたは5分ごとに実行します。

ユーザーがこれをどのように使用しているかを説明できる場合、より良い解決策があるかもしれません。

ACLを使用すると、誰が何を実行できるかをよりきめ細かく制御できます。実際のファイル所有権が自動的に変更されることはありません。私は、より高い視点を獲得し、それに基づいてソリューションを評価/再設計する必要があると思います。

あなたは使用することができ、ツールをinotifyを、以下のような簡単なbashスクリプトを記述します。Inotifyはディレクトリwebを監視し、ディレクトリ作成などのイベントがWebディレクトリ内で発生するたびに何かを行います 。多くのイベントが存在します。Googleで検索するか、このサイトをご覧ください

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done