web-dev-qa-db-ja.com

ファイルの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 student」権限が設定されていて、ユーザー「jack」にrw権限も付与している場合は、暗黙的にrw権限をだれにも付与します「学生」グループから。
    2. より厳密な（アクセス許可が少ない）ACLマスクは、対応する標準ファイルグループのアクセス許可を完全に削除できます。例えば。 rw標準ファイルグループ権限を持つファイルがあり、そのファイルに読み取り専用ACLマスクを適用すると、そのグループ権限は読み取り専用に減少します。次に、（setfacl -bコマンドを使用して）すべての拡張ACLエントリを削除すると、グループの権限は読み取り専用のままになります。これは、より厳密なACLマスクにのみ適用され、よりソフトなACLマスク（より多くのアクセス許可）は、元のファイルグループのアクセス許可が削除された後、永続的に変更しません。
filespermissionsacl
17
golem

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マスクとファイルグループのアクセス許可を組み合わせる理由は何ですか？その背後にある論理は何ですか？

良い説明は here です。本質的にはマスクは

[...]グループクラスのエントリが付与する権限の上限。

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

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

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

11
countermode

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

具体的には、そのマスクは基本的にNAMED USERとすべてのGROUP権限に取って代わり、機能します。これは、次の場合を意味します。

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

enter image description here

うまくいけば、これが役立ちます。

3
jjisnow

その背後にある論理は何ですか？

ロジックは完全に壊れているため、POSIX ACLは純粋で役に立たないナンセンスです。

ACLの概念を持たないアプリとの互換性を維持することを目的としていた場合 標準プリミティブなUNIXの「ugo」モデルでは、グループの権限をクリアするすべてのアプリがACLによって追加されたアクセスを効果的に撤回しているため、最初は実際に失敗しました。

0
poige