「所有者」権限が存在するのはなぜですか？グループ権限が足りませんか？

歴史

当初、Unixは自分が所属するユーザーとは異なるユーザーに対してのみ権限を持っていました。グループはありませんでした。具体的には、Unix バージョン 1 のドキュメントを参照してください。chmod(1)。したがって、他の理由がない場合は、以前のバージョンとの互換性のためにユーザーの権限が必要です。

グループは後で来ました。複数のグループがファイルへの権限に参加できるようにするACLは、はるかに後で登場しました。

表現力

ファイルに対する3つの権限がある場合、2つのファイルしかないよりも非常に低コスト（ACLよりもはるかに低い）でより細かい権限が可能です。たとえば、ファイルにモードがあるとしますrw-r-----。つまり、所有しているユーザーだけが書き込み可能で、グループから読み取ることができます。

別のユースケースは、グループでのみ実行できるsetuid実行可能ファイルです。たとえば、rwsr-x---モードを持つプログラムは、グループ内のユーザーだけがrootroot: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: ユーザーとグループへのアクセス。
• 644666または:664ユーザー、グループ、その他のアクセス権です。セカンダリ権限スキームは、これら3つのケースのうち2つですが、処理できます。 3番目にはACLが必要です。

一般的に使用されるディレクトリとプログラムの場合：

• 700または500：ユーザーアクセスのみ可能
• 750または710：グループアクセスのみ可能
• 755、、、または：ユーザー、グループ777、およびその他のアクセス権。ファイルにも同じ説明が適用されます。775751

上記は最も一般的に使用されますが、私が使用する権限設定の完全なリストではありません。 ACLが利用可能なすべての場合に、グループ（時にはディレクトリの固定グループビット）と組み合わせた上記の権限で十分です。

前述のように、ディレクトリリストに権限をリストするのは非常に簡単です。 ACLを使用せずにディレクトリリストのみを使用してアクセスを監査できます。 ACL ベースのシステムを使用する場合、権限を確認または監査することは非常に困難です。

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

すべてにACLを使用することは、「一目で」表示できる明確に定義された資格情報のサブセットがないことを意味します。出力には、ls -l標準（ユーザー/グループ/その他）権限、ユーザーとグループの名前、およびACLが関連付けられている項目の追加記号（または記号など）が+すべて1行に表示されます。@システムは、同等の機能を提供するためにACLの「最初の2つ」グループを認識する必要があります。

もう一つのことは、ファイルがまだ必要であることです。持つUNIXモデルの所有者（UNIX ACLはACLの変更が許可されている人を指定しないため）