「所有者」権限が存在する理由はありますか？グループ権限は十分ではありませんか？

Linuxでのファイルのアクセス許可の仕組みを理解していると思います。ただし、なぜ2つではなく3つのレベルに分割されているのか、私にはよくわかりません。

次の問題に回答してください。

• これは意図的な設計ですか、それともパッチですか？つまり、所有者/グループのアクセス許可は、何らかの論理的根拠とともに設計および作成されたのか、それとも次々にニーズに答えるために来たのか？
• ユーザー/グループ/その他のスキームは有用だが、グループ/その他のスキームでは十分ではないシナリオはありますか？

最初の質問に対する回答は、教科書または公式の掲示板のいずれかを引用する必要があります。

私が検討したユースケースは次のとおりです。

• プライベートファイル-ユーザーごとにグループを作成することにより、非常に簡単に取得できます。これは多くのシステムでよく行われています。
• 所有者（システムサービスなど）のみにファイルへの書き込みを許可し、特定のグループのみに読み取りを許可し、他のすべてのアクセスを拒否します-この例の問題は、グループが書き込みアクセスを持つ必要がある場合/ group / otherはそれで失敗します。両方の答えはACLを使用することであり、私見では、所有者の許可の存在を正当化しません。

NB superuser.comで質問を閉じた後、この質問を改良しました。

EDITが「... group / other ...」に「ただし、グループ/所有者スキームでは不十分」を修正しました。

歴史

本来、Unixには所有ユーザーと他のユーザーのみの許可がありました。グループはありませんでした。特にUnixバージョン1のドキュメントを参照してくださいchmod(1)。したがって、下位互換性には、他に何もないとしても、所有ユーザーの許可が必要です。

グループは後で来ました。ファイルのアクセス許可に複数のグループを含めることを許可するACLは、かなり後のことです。

表現力

1つのファイルに対して3つのアクセス許可を設定すると、2つだけのアクセス許可よりもきめの細かいアクセス許可が非常に低コストで（ACLよりもはるかに低い）許可されます。たとえば、ファイルはmodeを持つことができますrw-r-----。所有者のみが書き込み可能で、グループが読み取り可能です。

別の使用例は、1つのグループのみが実行可能なsetuid実行可能ファイルです。たとえば、モードrwsr-x---が所有root:admin者でadminあるプログラムでは、グループ内のユーザーのみがそのプログラムをルートとして実行できます。

「このスキームが表現できない許可があります」は、それに対する恐ろしい議論です。適用可能な基準は、コストを正当化する十分に一般的な表現可能なケースがあるかどうかです。この場合、特にユーザー/グループ/その他のトリプティックのその他の理由を考えると、コストは最小限です。

シンプルさ

ユーザーごとに1つのグループを作成すると、管理オーバーヘッドが小さくなりますが、重要ではありません。プライベートファイルの非常に一般的なケースがこれに依存しないことは良いことです。プライベートファイルを作成するアプリケーション（電子メール配信プログラムなど）は、ファイルにモード600を与えるだけでよいことを知っています。ユーザーのみを含むグループを探してグループデータベースを走査する必要はありません。そのようなグループが存在しない場合、または複数存在する場合はどうしますか？

別の方向から来て、ファイルが表示され、そのアクセス許可を監査する（つまり、ファイルが本来あるべきものであることを確認する）とします。グループ定義をたどる必要があるときよりも、「ユーザーだけがアクセスできる、次はいい」ということができる方がはるかに簡単です。（このような複雑さは、ACLや機能などの高度な機能を多用するシステムの悩みの種です。）

直交性

各プロセスは、特定のユーザーおよび特定のグループとしてファイルシステムアクセスを実行します（補助グループをサポートする現代のユニスに関するより複雑なルールを使用）。ユーザーは、ルート（uid 0）およびシグナル配信許可（ユーザーベース）のテストなど、多くのことに使用されます。プロセスのアクセス許可でユーザーとグループを区別することと、ファイルシステムのアクセス許可でユーザーとグループを区別することには自然な対称性があります。

これは意図的な設計ですか、それともパッチですか？つまり、所有者/グループのアクセス許可は、何らかの論理的根拠とともに設計および作成されたのか、それとも次々にニーズに答えるために来たのか？

ファイルに対するユーザー/グループ/その他の権限は、元のUnixデザインの一部です。

ユーザー/グループ/その他のスキームは有用だが、グループ/所有者のスキームでは十分ではないシナリオはありますか？

はい、セキュリティとアクセス制御が重要であると想像できるほぼすべてのシナリオ。

例：システム上のいくつかのバイナリ/スクリプトをに実行のみのアクセスを許可しother、読み取り/書き込みアクセスをに制限したい場合がありrootます。

所有者/グループのアクセス許可のみを持つファイルシステムのアクセス許可モデルについて、何を念頭に置いているのかわかりません。otherカテゴリが存在しない場合、安全なオペレーティングシステムをどのように使用できるかわかりません。

編集： ここでのgroup/otherアクセス許可だけが必要な場合、暗号化キーを管理する方法、または適切なユーザーのみがメールスプールにアクセスできる方法を考案することをお勧めします。秘密鍵のuser:user所有権が厳密に必要な場合もありますが、user:group所有権を与えることが理にかなっている場合もあります。

プライベートファイル-ユーザーごとにグループを作成することにより、非常に簡単に取得できます。これは多くのシステムでよく行われています。

これは簡単に実行できotherますが、グループの存在でも同じように簡単に実行できます...

所有者（システムサービスなど）のみにファイルへの書き込みを許可し、特定のグループのみに読み取りを許可し、他のすべてのアクセスを拒否します。この例の問題は、グループに書き込みアクセス権が必要になると、ユーザーが/ group / otherはそれで失敗します。両方の答えはACLを使用することであり、私見では、所有者の許可の存在を正当化しません。

otherUnixファイルシステムのアクセス許可のカテゴリの論理的な必要性についての私の主張を繰り返していると思われるあなたの声明の一部を強調しました。

あなたが考えているようなファイルシステムの設計（私が知ることができるものから）は、安全でないか扱いにくいでしょう。Unixは非常に優秀な人々によって設計されたものであり、彼らのモデルはセキュリティと柔軟性の可能な限り最良のバランスを提供すると思います。

これは意図的な設計ですか、それともパッチですか？つまり、所有者/グループのアクセス許可は、何らかの論理的根拠とともに設計および作成されたのか、それとも次々にニーズに答えるために来たのか？

はい、これは初期の頃からUNIXに存在していた意図的な設計です。メモリがKB単位で測定され、今日の標準ではCPUが非常に遅いシステムに実装されました。このようなルックアップのサイズと速度が重要でした。ACLはより多くのスペースを必要とし、より遅くなります。機能的には、everyoneグループは他のセキュリティフラグで表されます。

ユーザー/グループ/その他のスキームは有用だが、グループ/所有者のスキームでは十分ではないシナリオはありますか？

ファイルアクセスによく使用するアクセス許可は次のとおりです（簡単にするためにビット値を使用していますが、これは通常、ビット値を設定するためです）。

• 600または400：ユーザーのみのアクセス（そして、はい、ユーザーに読み取り専用アクセスを許可します）。
• 640または660：ユーザーおよびグループアクセス。
• 644、666または664：ユーザー、グループ、およびその他のアクセス。2レベルの許可スキームでは、これら3つのケースのうち2つしか処理できません。3番目にはACLが必要です。

私がよく使用するディレクトリとプログラムの場合：

• 700または500：ユーザーのみのアクセス
• 750または710：グループのみのアクセス
• 755、777、775、または751：ユーザー、グループ、および他のアクセス。ファイルと同じコメントが適用されます。

上記は最も一般的に使用されますが、私が使用する許可設定の完全なリストではありません。上記のアクセス許可とグループ（ディレクトリにスティッキグループビットが含まれる場合があります）を組み合わせれば、ACLを使用したすべてのケースで十分です。

上記のように、ディレクトリリストに許可をリストするのは非常に簡単です。ACLが使用されていない場合、ディレクトリリストのみでアクセス許可を監査できます。ACLベースのシステムで作業するとき、アクセス許可を確認または監査することは非常に困難です。

ユーザー/グループ/その他の許可システムは、ACLが発明される前に設計されました。UNIXの初期に遡りますので、ACLで問題を解決する必要があるとは言えません。ACLの概念が明白に思えても、固定量ではなく、各ファイルで可変量の許可情報を保存および管理するために、かなりの量の余分なオーバーヘッドが必要でした。

すべてにACLを使用することは、「一目で」表示できる許可情報の明確に定義されたサブセットがないことも意味します。の出力にls -lは、標準（ユーザー/グループ/その他）のアクセス許可、ユーザーとグループの名前、ACLが関連付けられているエントリの追加表記（+または@記号）がすべて1行で表示されます。システムでは、ACLの「上位2」グループを識別して同等の機能を提供する必要があります。

追加のポイントとして、ファイルはまだする必要が持っている UNIXのACLは、ACLを変更することが許可されている人のために提供していないので、UNIXモデルの所有者。