setuid ビットと setgid ビットは、まったく別の目的で考案されたことを思い出してください。ファイルを実行しているユーザーの uid または gid ではなく、所有者の uid または gid で実行可能ファイルを実行させることです。その他の使用法は単なる追加機能です。
これらのビットは、実行可能でない通常のファイルでは機能しません。 (また、セキュリティ上の問題により、一部のディストリビューションではシェル スクリプトも使用されます。) もともと、これらにはディレクトリに対する機能もありませんでした。明らかに、ディレクトリで未使用の setgid を取得し、それを使用してグループ所有権の一貫性を確保するのはクールだろうと誰かが判断しました。結局のところ、グループの所有権をいじっているのであれば、それは複数の人がそのファイルを操作しているからであり、特定のディレクトリ内のすべてのファイルが誰が作成したかに関係なく、同じグループに属していることがおそらく理にかなっています。だれかが newgrp を実行し忘れたことによる面倒が解消されます。
では、setuid とファイル uid に同じ機能を実装してみませんか? uid は gid よりもはるかに基本的なものです。これを実装すると、多くの場合、ファイルはそれを作成したユーザーのものではなくなります!おそらく、ユーザーは引き続きファイルを変更できますが (umask が正常であると仮定して)、許可ビットを変更することはできません。その有用性を理解するのは難しい.
この質問への答えは、最新の Unix ライクな OS のほとんどが「ファイル プレゼント」を許可しない結果となった「ファイル プレゼント」セキュリティ問題に関係していると思います。 「ファイルプレゼント」とは、スーパーユーザー以外のユーザーがファイルの所有権をそのユーザー以外の誰かに変更することです。この機能により、多くのいたずらの機会が提供されます。
ファイルのプレゼントは許可されていないため、別の形式で同じ機能を実行するディレクトリの setuid は許可されないか、設定されていても無視されます。
動作の変更に関しては、OS ライブラリとユーティリティを変更する必要があります。
これを実装するための非常に良い使用例は次のとおりです:
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 は root になり、所有者と UID も root になります。他の権限は -wx になります .これにより、すべてのユーザーがアップロード ディレクトリへの書き込みアクセスを許可されますが、一度アップロードされると何も読み取ることができず、ルートが新しく作成されたすべてのファイルを所有します。
そのため、ディレクトリの UID 機能を GID ビットと一致させるには、完全に適切で有効な使用例が 2 つあります。
スティーブン・マーキュリオ