ファイルのACLマスクと標準グループ許可を関連付ける関係は何ですか？

最初にファイルを作成し、標準のアクセス許可とACLエントリを確認します。

$ touch file; ls -l file; getfacl file
-rw-r--r-- 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
other::r--

次に、ファイルにACLマスクを設定し、標準のアクセス許可とACLエントリを再度確認します。

$ setfacl -m mask:rwx file
$ ls -l file; getfacl file
-rw-rwxr--+ 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
mask::rwx
other::r--

ACLマスクとともに、ファイルの標準グループ権限も変更されることに注意してください。

1. ACLマスクと標準グループパーミッションの間にどのような接続が存在しますか？
2. ACLマスクとファイルグループのアクセス許可を結合する理由は何ですか？その背後にあるロジックは何ですか？

問題のディストリビューションはDebian Linux 7.6およびCentOS 7です。

編集

この時点で、標準のファイルグループのアクセス許可とACLマスクの関係を調査しているときに思いついた私の発見をいくつか共有したかっただけです。ここに私が見つけた経験的観察があります：

1. ACLマスクは変更できます。

   1. setfacl -m m:<perms>コマンドで直接設定する。
   2. chmodコマンドでファイルグループのアクセス許可を変更する（ACLマスクが既に存在する場合。ファイルに名前付きユーザーまたはグループACLアクセス許可がない場合はオプションであるため、存在しない場合があります）。
   3. 名前付きユーザーまたはグループACLエントリを追加することにより（マスクは自動的に再計算されます）。

2. マスクは、マスクがsetfaclによって直接設定されている場合、またはchmod（自動計算ではない）を使用したファイルグループのアクセス許可の変更によってのみ設定されている場合にのみ、最大アクセス権を適用します（ACLマスクアクセス許可を超えるアクセス許可を持つACLエントリが存在する場合）。ACLエントリを変更すると、ACLマスクの自動再計算がトリガーされ、「強制モード」が事実上オフになります。

3. ACLを使用する場合、標準のファイルグループのアクセス許可に暗黙的に影響する副作用がいくつかあります。

   1. ファイルに適用された名前付きユーザーまたはグループのACLエントリは、ACLマスクを変更する（アクセス許可を増やす）ため、有効なファイルグループアクセス許可を変更できます。たとえば、ファイル所有者として「rw-r--r-- jim Students」権限が設定されており、ユーザー「r」にrw権限も付与している場合、暗黙的に誰にもrw権限を付与します「学生」グループから。
   2. より厳密な（アクセス許可が少ない）ACLマスクは、対応する標準ファイルグループのアクセス許可を永久に削除できます。たとえば、rw標準ファイルグループ権限を持つファイルがあり、そのファイルに読み取り専用ACLマスクを適用すると、そのグループ権限は読み取り専用に低下します。その後、すべての拡張ACLエントリを（setfacl -bコマンドで）削除すると、グループのアクセス許可は読み取り専用のままになります。これは、より厳密なACLマスクにのみ適用されます。より柔らかいACLマスク（より多くのアクセス許可）は、削除された後に元のファイルグループのアクセス許可を永続的に変更しません。

UNIXファイルのアクセス許可がaclエントリと一致しない場合、またはその逆の場合は意味がありません。したがって、マニュアルページ（acl(5)）には、あなたが求めるものが記載されています。

ACLエントリとファイル許可ビットの対応

ACLで定義された許可は、ファイル許可ビットで指定された許可のスーパーセットです。

ファイルの所有者、グループ、その他のアクセス許可と特定のACLエントリには対応関係があります。所有者のアクセス許可はACL_USER_OBJエントリのアクセス許可に対応します。ACLにACL_MASKエントリがある場合、グループ許可はACL_MASKエントリの許可に対応します。それ以外の場合、ACLにACL_MASKエントリがない場合、グループのアクセス許可はACL_GROUP_OBJエントリのアクセス許可に対応します。他のアクセス許可は、ACL_OTHER_OBJエントリのアクセス許可に対応しています。

ファイルの所有者、グループ、およびその他のアクセス許可は、対応するACLエントリのアクセス許可と常に一致します。ファイル許可ビットを変更すると、関連するACLエントリが変更され、これらのACLエントリを変更すると、ファイル許可ビットが変更されます。

議論への回答の補遺：

ACLマスクとファイルグループのアクセス許可を結合する理由は何ですか？その背後にあるロジックは何ですか？

良い説明はこちらです。本質的には、マスクは

[...]グループクラスのエントリが許可するアクセス許可の上限。

この上限プロパティにより、ACLを認識しないPOSIX.1アプリケーションが、ACLがサポートされると突然、予期せずに追加のアクセス許可の付与を開始することがなくなります。

最小限のACLでは、グループクラスのアクセス許可は所有グループのアクセス許可と同じです。拡張ACLでは、グループクラスに追加のユーザーまたはグループのエントリを含めることができます。これにより、問題が発生します。これらの追加エントリの一部には、所有グループエントリに含まれていないアクセス許可が含まれているため、所有グループエントリのアクセス許可がグループクラスのアクセス許可と異なる場合があります。

この問題は、マスクエントリのおかげで解決されます。最小限のACLを使用すると、グループクラスのアクセス許可は所有するグループエントリのアクセス許可にマップされます。拡張ACLを使用すると、グループクラスのアクセス許可はマスクエントリのアクセス許可にマップされますが、所有グループエントリは引き続き所有グループのアクセス許可を定義します。グループクラスのアクセス許可のマッピングは一定ではなくなりました。

このリンクを見たときに、何が起こっているのかを正確に理解しましたACLの処理

具体的には、そのマスクは基本的に、NAMED USERおよびすべてのGROUP権限の代わりになり、それらを置き換える機能を果たします。これは、次の場合に意味します。

1. マスクを調整し、グループの最大許可を変更します。
2. マスクが存在するグループ許可のいずれかを変更すると、マスクはすべてのグループ許可の最大グループ許可を取ります
3. グループの読み取り、書き込み、および実行の許可は、マスク（存在する場合）に基づいて決定されます

これがお役に立てば幸いです。

その背後にあるロジックは何ですか？

ロジックは完全に壊れているため、POSIX ACLは純粋で無駄です。

標準プリミティブUNIXの「ugo」モデル以外のACLの概念を持たないアプリとの互換性を維持しようとしていた場合、グループの権限をクリアするすべてのアプリがACLによって追加されたアクセスを事実上取り消すため、最初は実際に失敗しました。