web-dev-qa-db-ja.com

ACLはファイルの有効なアクセス許可をどのように計算しますか？

次のコマンドを実行して、作成された新しいファイルとサブディレクトリに対するwheel group rwx権限を付与しました。

[belmin@server1]$ ls -la
total 24
drwxr-sr-x+   2 guards guards  4096 Aug 27 15:30 .
drwxr-xr-x  104 root   root   12288 Aug 27 15:19 ..

[belmin@server1]$ Sudo setfacl -m d:g:wheel:rwX .

[belmin@server1]$ getfacl .
# file: .
# owner: guards
# group: guards
# flags: -s-
user::rwx
group::r-x
group:wheel:rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:wheel:rwx
default:mask::rwx
default:other::r-x

ただし、rootとしてファイルを作成すると、effective権限の計算方法が完全にわかりません。

[belmin@server1]$ Sudo touch foo

[belmin@server1]$ getfacl foo
# file: foo
# owner: root
# group: guards
user::rw-
group::r-x                      #effective:r--
group:wheel:rwx                 #effective:rw-
group:guards:rwx                #effective:rw-
mask::rw-
other::r--

誰かがこれが何を意味するかについて詳しく説明できますか？

linuxfilespermissionsacl
9
Belmin Fernandez

effective権限は、実際の（実際の？）権限とmaskのANDをとることによって形成されます。ファイルのmaskはrw-、すべてのeffective権限でxビットがオフになっています。

8
G-Man Says 'Reinstate Monica'

短い回答：実行ビットをオンにしてマスクしたい場合は、setfaclの後にtouchを使用して明示的に設定する必要があります。セキュリティはその暗黙の設定を禁止します。

setfacl -n -m m::rwx foo

"-n"は、マスクの再計算を抑制します（必要ない場合があります）。
"m :: rwx"は、マスク値を「rwx」に設定します。 「m :: x」はすべての読み取りと書き込みを無効にすることに注意してください。

マスクが「rw-」である理由を示すことができません。 OPの例全体で、touchがファイルを作成するデフォルトのディレクトリは変更されていないと想定しています。

  1. 'foo'のディレクトリエントリは、所有者 'root'を表示する必要があります（Sudoコマンドとグループ 'guards'のため、ディレクトリにはSUIDビットが設定されているためです。権限はデフォルトで '-rw -... r--'となります。ディレクトリ '-... rx ...'のグループ権限（SUIDビットが小さなsとして表示されるため）。

  2. 次はACLesです。これはディレクトリのデフォルトです。 ACLが継承することを考えると、ACLeが作成され、ACLEマスクがディレクトリのデフォルトの「rwx」であるとは想定していません。

しかし、それらが作成された場合は、新しいACLeがデフォルトから準備され、マスクを「rwx」のままにすることを期待します。それらがデフォルトから準備されていない場合、これはデフォルトACLの概念を無効にするように見えます。「デフォルト」ACLは名前付きユーザーと名前付きグループのACLのみを提供します。

これは、ACLeのマスクがどうあるべきかという疑問を投げかけます。デフォルトのマスクエントリからは「rwx」であると思います。しかし、それは空白のマスクで作成することができ、それからあらゆる種類の法律が適用されます。

  1. User :: rw-、group :: rx、other :: r-、group：wheel：rwx、group：guards：rwx、およびmask :::（未設定）の暫定ACLを使用して、setfaclのドキュメントを参照します、同じルールがファイル作成に適用されると仮定します。

条項があります：

ACLに名前付きユーザーまたは名前付きグループのエントリが含まれていて、マスクエントリが存在しない場合、グループエントリと同じ権限を含むマスクエントリが作成されます。

これにより、ACLグループエントリがファイルディレクトリエントリから作成された場合はACLマスクが「r-x」に、ACLグループエントリがデフォルトACLから取得された場合は「r-x」に設定されます。 （どちらにしても、この場合の結果は同じです。）

条項もあります：

デフォルトACLに名前付きユーザーエントリまたは名前付きグループエントリが含まれ、マスクエントリが存在しない場合、デフォルトのデフォルトACLのグループエントリと同じ権限を含むマスクエントリが追加されます。 ...マスクエントリの権限は、マスクエントリによって影響を受けるすべての権限の和集合を含むようにさらに調整されます。

このルールが適用される場合、マスクは「r-x」（前の句と同じロジック）で始まり、「マスクエントリによって影響を受けるすべてのアクセス許可の結合」になるように調整されます。

「マスクエントリの影響を受ける権限」は、setfaclコマンドのドキュメントでは定義されていません。 POSIX ACLドキュメントは言う：

マスクは、所有グループのすべてのアクセス許可と、すべてのユーザーおよびグループエントリの組み合わせです。

付加的である「結合」という言葉を与えると、私は「組み合わせ」を論理的論理和であると読みます。つまり、グループまたはユーザーのACLeに「x」権限がある場合、マスクには「x」が含まれます。

  1. このすべてのロジックにより、OPの例のマスク値は「rwx」である必要があり、どの論理パスをたどったかは関係ありません。

実行のxはマスクに表示されないため、上記の推論には欠陥があるはずです。

したがって、一般的なドキュメントソースから「非表示」にされたマスクの計算方法に関するいくつかのルールが必要です（またはバグが見つかりました）。

私の結論は、「x」は常に無条件に削除され、ドキュメントは緩いということです。

この変更はおそらく「セキュリティ」の正当化に基づいて行われたものです。暗黙的に実行可能なファイルはありませんが、作成後に実行可能ビットをオンにする必要があります。

7
HiTechHiTouch