ディレクトリで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つの安全なサイトを持つマルチサイトサーバーがあるとします。あなたは3つのグループを作成しました。それぞれのサイトのメンテナごとに1つです。すべてのサイトのすべてのファイルは、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はすべてのコンテンツを提供でき、ユーザーはアップロードされたファイルの所有権の変更について心配する必要がありません。
もう1つの使用例は、匿名のftp/httpまたはsftp/sshのアップロードです。アップロードディレクトリのグループとGIDはrootになり、所有者とUIDも同様になります。その他の権限は-wx。これにより、誰でもアップロードディレクトリへの書き込みアクセスが許可されますが、アップロードされた後は何も読み取ることができず、ルートは新しく作成されたすべてのファイルを所有します。
したがって、ディレクトリのUID機能を有効にしてGIDビットと一致させるには、2つの完全に適切で有効な使用例があります。
スティーブン・メルクリオ
パーティーには少し遅れますが、将来の読者がこれに遭遇した場合のために;）他の人が述べたように、標準のOS-Xファイルシステムでは、ディレクトリのsetUIDは無視されます-これを回避する簡単な方法はないようです（ mount -o ....または何でないか）。そのため、manページは実際には、文字どおりOS-Xの動作に準拠していません。
4000（set-user-ID-on-execution bit）[...] set-user-idビットが設定されたディレクトリは、その中に作成されたすべてのファイルとサブディレクトリを、作成プロセスのuid [...]
しかし、元の所有権を放棄することなく同じ効果を達成する可能性も示しています。 Linuxは同様の効果のために「[g /] setfacls」を使用します（これらは一見実際には表示されない権限なので、迷惑になる場合があります）。
「どうすれば同様の効果を達成できるか」については、manページ全体を読み、次のようにいじってください。
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
まあ、それは標準を尊重する必要があります。 sftpdのみのかなりの数の状況で、sshdが行うaclとacl-mask-setと、そのマスクに対して実行する必要があるリセットの両方で、多くの問題を回避できると思います。
デフォルトではセキュリティは非常に便利ですが、それをオプションにしない場合は、winghtmareを作成するだけです。
https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html
いずれにせよ、それはLinuxが現在行っていることなので、それらを回避するにはaclを使用するだけです。