web-dev-qa-db-ja.com

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

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

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

そう：

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

私は定期的にcronジョブを使用してディレクトリ全体をサーフィンできると思いますが、これは本質的に1回のpr-fileコマンドでは効率が悪いと感じます。

INotifyを使用して example を見つけましたが、スクリプトを必要とするため、メンテナンスが非常に困難です。

ACLが所有権の強制で私を助けることができるかどうか、私は理解できませんでした。

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

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

debianpermissionsfilesystems
22
Martin Nielsen

デフォルトの所有者を「自動的に」設定するには、ディレクトリ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)権限。
  • 他のユーザーにはデフォルトで権限はありません。 othersはいずれにせよ_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がdefault権限を設定することです。したがって、アイテムの所有者は、それに関連付けられている権限を変更できます。たとえば、_user2_は完全に実行できます...

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

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

ただし、元々はグループ内のすべてのユーザーに完全なrwsアクセス権を与えるつもりなので、これらのユーザーを信頼していて、ユーザーからの悪意のある操作が多すぎることはないと想定しています。

14
John WH Smith

これを行うには、よりスマートな方法があります。これは、set-gidとdefault aclsの組み合わせを使用します。もちろん、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で作成されたファイルは、ディレクトリのsetgidビットによってそのグループがsharingに設定されることを意味します。さらに、特定のユーザーまたはグループでACLを指定しなかったため、デフォルトのACLを継承し、デフォルトのLinuxスタイルの権限をオーバーライドします。これは、すべてのファイルが所有権<user>:sharingおよび権限rw-rw----で作成されることを意味します。ディレクトリも同じですが、独自のデフォルトACLが親（/var/grpdir）と同じに設定され、ユーザーとグループに実行可能ビットが設定される点が異なります。 sharingグループからユーザーを削除すると、そのユーザーはディレクトリにアクセスできなくなります（所有している場合でも、ディレクトリ内のファイルにはアクセスできません）。

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

6
sirlark

私はこれを行うための良い方法を知りません。技術的に最もクリーンな方法は、それを行うFuseファイルシステムです。もちろん、まだ誰もそれをしていなければ、多くの作業が必要です。

代替案：

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

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

2
Hauke Laging

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

その場合、パンディアが述べたように、あなたの最善の策は、chown -Rフラグを指定したcronジョブであると思います。 cronに入れて、毎分または5分ごとに実行します。

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

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

0
Baazigar

inotify-tools を使用して、以下のような簡単なbashスクリプトを記述できます。 Inotifyはディレクトリwebを監視し、dir creationは、Webディレクトリ内で発生します。多くのイベントが存在します。あなたはそれをググることができますまたはこれを見ているかもしれません site

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