ディレクトリでsetuidが無視されるのはなぜですか？

Linuxシステムでは正常に実行できますが、予想どおり、chmod u+s $some_directory新しいサブディレクトリとファイルの所有権を格納ディレクトリの所有者に強制する（およびサブディレクトリu+sを設定する）代わりに、システムはsetuidビットを無視します。サブディレクトリとファイルは、作成プロセスのUIDを継承し続け、サブディレクトリはデフォルトではsetuidされません。

ディレクトリでsetuidが無視されるのはなぜですか？システムにそれを認識させるにはどうすればよいですか？

setuidおよびsetgidビットは完全に異なる目的で発明されたことを思い出してください：実行可能ファイルを、ファイルを実行しているユーザーのuidまたはgidではなく、所有者のuidまたはgidで実行します。その他の使用法は、単なる追加機能です。

これらのビットは、実行可能でない通常のファイルでは機能しません。（また、セキュリティの問題のため、一部のディストリビューションのシェルスクリプトも。）元々、それらにはディレクトリの機能もありませんでした。明らかに誰かが、ディレクトリで未使用のsetgidを取得し、それを使用してグループ所有権の一貫性を強化するのはクールだと判断しました。結局のところ、グループの所有権で遊んでいるのは、複数の人がファイルを操作しているからです。特定のディレクトリ内のすべてのファイルが、だれが作成したかに関係なく、同じグループに属することはおそらく理にかなっています。誰かがnewgrpを実行するのを忘れたための手間がなくなりました。

では、setuidとファイルuidに同じ機能を実装してみませんか？さて、uidはgidよりもはるかに基本的です。これを実装すると、多くの場合、ファイルはそれを作成したユーザーのものではなくなります。おそらく、ユーザーはファイルを変更できますが（umaskが正気であると仮定して）、許可ビットを変更することはできません。その有用性を見ることは難しい。

この質問に対する答えは、最新のUnixライクなOSが「ファイルのプレゼント」を許可しないという「ファイルのプレゼント」のセキュリティ問題に関係していると思います。「ファイルのプレゼント」とは、スーパーユーザー以外のユーザーがファイルの所有権をそのユーザー以外のユーザーに変更することです。この機能は、いたずらの機会を多く提供します。

ファイルの提供は許可されていないため、別の形式で同じ機能を実行するディレクトリのsetuidは許可されないか、設定されている場合は無視されます。

動作の変更については、OSライブラリとユーティリティを変更する必要があります。

これを実装するための非常に良いユースケースの1つは次のとおりです。

3つの安全なサイトを持つマルチサイトサーバーがあるとしましょう。異なるサイトメンテナーごとに1つずつ、3つのグループを作成しました。すべてのサイト内のすべてのファイルは、Apacheがファイルを読み書きできるように、Apacheユーザーが所有する必要があります（drupal / wordpressなど）。

setuidがディレクトリ権限のsetgidビットのように機能した場合、次のようになります。

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

このように、メンテナーの各グループは自分のコンテンツのみを表示および操作できますが、WebサーバーのユーザーApacheはすべてのコンテンツを提供でき、ユーザーはアップロードされたファイルの所有権を変更する必要がありません。

別のユースケースは、匿名ftp / httpまたはsftp / sshアップロードです。アップロードディレクトリのグループとGIDはルートになり、所有者とUIDもルートになります。他の許可はになります-wx。これにより、誰でもアップロードディレクトリへのWRITEアクセスが許可されますが、アップロードされた後は何も読み取ることができず、rootは新しく作成されたすべてのファイルを所有します。

そのため、ディレクトリのUID機能をGIDビットに一致させるための2つの完全に優れた有効なユースケースがあります。

スティーブン・マーキュリオ

パーティーに少し遅れましたが、将来の読者がこれに遭遇した場合に備えて;）他の人が述べたように、標準OS-XファイルシステムではディレクトリのsetUIDは無視されます-そしてこれを回避する簡単な方法はないようです（mount -o....またはそうではない）。よくあることですが、manページは実際にはOS-Xの動作に準拠していません。

4000（実行時のユーザーIDの設定ビット）[...]ユーザーIDのビットが設定されたディレクトリは、それらで作成されたすべてのファイルとサブディレクトリを、ディレクトリ所有者ではなく、所有者に強制します。作成プロセスのuid [...]

しかし、元の所有権を放棄せずに同じ効果を達成する可能性もリストしています。Linuxは同様の効果のために「[g /] setfacls」を使用します（これらは一見実際には見えない許可なので、邪魔になることがあります）。

「同様の効果をどのように実現できますか」については、マニュアルページ全体を読み、以下をいじってください。

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

経由で確認できます

ls -le

すべてが正常に見える場合。その他のオプションには、特定の位置へのルールの挿入、特定のルールの削除または置換が含まれます。ここで注目すべき2つのオプションは、「」file_inheritとdirectory_inherit「ルール」を新しいディレクトリ/ファイルに添付できるようにすることです。

私はsetUIDの使用はあまり好きではありませんが、単に「メイン」グループの設定が機能しないか、クライアントがグループ書き込みを許可しないファイルマスクを持っているファイルサーバーでは、setGIDは非常に便利です。それは以下によって解決されます：

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

まあ、それは標準を尊重する必要があります。sftpのみでかなりの数のシナリオを考えると、sshdが行うaclとacl-mask-set、およびそのマスクに対して行わなければならないリセットの両方で、多くのトラブルを軽減できると思います。

デフォルトではセキュリティは非常に便利ですが、オプションにしない場合は、winghtmareを作成するだけです。

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

いずれにせよ、Linuxの現在の状況なので、aclを使用してそれらを回避してください。

http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directoriesによると、UNIXおよびLinuxシステムの両方のディレクトリのsetuidビットは無視されます。ただし、FreeBSDでは期待どおりに動作させることができます。