歴史
元々、Unix は所有ユーザーに対してのみパーミッションを持ち、他のユーザーに対してはパーミッションを持っていました。グループはありませんでした。 Unix バージョン 1、特に chmod(1) のドキュメントを参照してください。 .そのため、下位互換性を維持するには、所有ユーザーのアクセス許可が必要です。
グループは後で来ました。ファイルのアクセス許可に複数のグループを含めることを許可する ACL は、ずっと後に登場しました。
表現力
1 つのファイルに 3 つのアクセス許可を設定すると、2 つだけのアクセス許可よりもきめ細かいアクセス許可が可能になり、コストも非常に低くなります (ACL よりもはるかに低くなります)。たとえば、ファイルはモード rw-r----- を持つことができます :所有ユーザーのみが書き込み可能、グループは読み取り可能。
もう 1 つの使用例は、1 つのグループによってのみ実行可能な setuid 実行可能ファイルです。たとえば、モード rwsr-x--- のプログラム root:admin が所有 admin のユーザーのみを許可します ルートとしてそのプログラムを実行するためのグループ。
「このスキームでは表現できない権限がある」というのは、それに対するひどい議論です。適切な基準は、コストを正当化する十分な一般的な表現可能なケースがあるかということです。この例では、特にユーザー/グループ/その他のトリプティクの他の理由を考えると、コストは最小限です。
シンプルさ
ユーザーごとに 1 つのグループを使用すると、管理オーバーヘッドがわずかではありますが、重要ではありません。プライベート ファイルの非常に一般的なケースがこれに依存しないのは良いことです。プライベート ファイルを作成するアプリケーション (電子メール配信プログラムなど) は、ファイルにモード 600 を指定するだけでよいことを認識しています。ユーザーのみを含むグループを探すためにグループ データベースをトラバースする必要はありません。そのようなグループがない場合、または複数ある場合はどうすればよいですか?
別の方向から来て、ファイルを見て、そのパーミッションを監査したいとします (つまり、パーミッションがどうあるべきかをチェックします)。グループ定義をたどる必要がある場合よりも、「ユーザーのみがアクセスできるようにする」ことができる方がはるかに簡単です。 (このような複雑さは、ACL や機能などの高度な機能を多用するシステムの悩みの種です。)
直交性
各プロセスは、特定のユーザーおよび特定のグループとしてファイルシステムへのアクセスを実行します (補助グループをサポートする最新のユニックスでは、より複雑なルールが適用されます)。ユーザーは、ルート (uid 0) やシグナル配信許可 (ユーザーベース) のテストなど、多くのことに使用されます。プロセス許可でユーザーとグループを区別することと、ファイルシステム許可でユーザーとグループを区別することの間には自然な対称性があります。
<ブロック引用>
これは意図的な設計ですか、それともパッチですか?つまり、所有者/グループのアクセス許可は、なんらかの根拠とともに設計および作成されたのでしょうか?それとも、必要に応じて次々と作成されたのでしょうか?
ファイルに対するユーザー/グループ/その他のアクセス許可は、オリジナルの Unix 設計の一部です。
<ブロック引用>ユーザー/グループ/その他のスキームは役に立ちますが、グループ/所有者のスキームでは不十分なシナリオはありますか?
はい、事実上、セキュリティとアクセス制御が重要であると想像できるすべてのシナリオです。
例:システム上のいくつかのバイナリ/スクリプトに、other への実行のみのアクセスを許可したい場合があります。 、および読み取り/書き込みアクセスを root に制限したままにします .
所有者/グループのアクセス許可のみを持つファイル システムのアクセス許可モデルについて、あなたが何を考えているのかわかりません。 other が存在しなければ、安全なオペレーティング システムを使用する方法がわかりません。
編集: ここで group/other を意味していたとします。 必要なのはアクセス許可だけです。暗号化キーを管理する方法や、適切なユーザーのみがメール スプールにアクセスできるようにする方法を考案することをお勧めします。秘密鍵が厳密に user:user 必要な場合があります user:group を与えることが理にかなっている他のケース
プライベート ファイル - ユーザーごとにグループを作成することで非常に簡単に取得できます。これは、多くのシステムでよく行われていることです。
これは簡単に実行できますが、other があれば簡単に実行できます。 グループ...
所有者 (システム サービスなど) のみにファイルへの書き込みを許可し、特定のグループのみに読み取りを許可し、他のすべてのアクセスを拒否します。 - この例の問題点は、グループに書き込みアクセス権が必要になると、ユーザー/グループ/その他がそれで失敗することです。両方の答えは ACL を使用することであり、私見ですが、所有者のアクセス許可の存在を正当化するものではありません。
other の論理的必要性についての私の主張を繰り返しているように見えるあなたの声明の部分を強調しました Unix ファイル システム権限のカテゴリ
あなたが考えているように見えるようなファイルシステムの設計 (私が知る限り) は、安全でないか扱いにくいものです。 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 ベースのシステムを使用していると、アクセス許可の確認や監査が非常に難しいことがわかります。