web-dev-qa-db-ja.com

ACLマスクのデフォルト値

これは、システム管理者としてのインタビューで直面した質問です。

マスク値を設定しなかった場合、マスクのデフォルト値は何ですか？

マスクを設定しなければ、それはrwxになるはずだと思っていました。

例えば：

> touch testfile
> getfacl testfile
# file: testfile
# owner: chenicha
# group: csgrad
user::rw-
group::r--
other::r--

マスクのステータスは記載されていませんが、rwxである必要がありますね。

linuxaccess-controlunix
3
Coda Chang

ACLを適用しない場合は、maskは必要ありません。 this によれば、

マスクエントリは、必要なときに自動的に作成されますが、提供されません。

そして this によると、最小限のACLを使用すると、マスクは追加されません。

 [arif@arif blabla]$ ls -ldha .
 drwxrwxr-x. 2 arif arif 4.0K Oct 17 06:13 .
 [arif@arif blabla]$ getfacl --omit-header .
 user::rwx
 group::rwx
 other::r-x

[arif@arif blabla]$ chmod g-wx .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::r--
other::r-x

[arif@arif blabla]$ setfacl -m g::rw .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::rw-
other::r--

this によれば、

拡張ACLにはマスクエントリも含まれており、名前付きユーザーと名前付きグループのエントリをいくつでも含めることができます。

したがって、ここでは、拡張されたACLを使用します。これにより、maskエントリにgroup class権限がマップされます ここ 、

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

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

[arif@arif blabla]$ setfacl -m g:wheel:rw .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::rw-
group:wheel:rw-
mask::rw-
other::r--

ここでは、特定のmaskを定義しているにもかかわらず、グループクラス権限の値がmaskにマップされていることがわかります。また、このマッピングアプローチは、アプリケーションがACLをサポートしているかどうかに関係なく、アプリケーションのスムーズな相互作用を保証します。 group class permissionビットをmaskとして使用する理由は、次のように TRUSIXドキュメント で説明されています。

ファイルグループのクラス許可ビットは、所有グループによる許可されたデフォルトアクセスを奨励していますが、推奨されるマスキングフィールドです。ファイルの所有者クラスを使用すると、「所有者のみ」のアクセスを確立しようとするプログラムで互換性の問題が発生するため、この選択を行う必要があります。プレゼント。ユーザーエントリをファイル所有者クラス許可ビットでマスクし、グループエントリをファイルグループクラス許可ビットでマスクする追加のオプションには、ファイル所有者クラスのみをマスクするのと同じ欠点があります。

ですから、maskのデフォルト値はgroup class許可値と同じであると言えるでしょう。

0
Muhammad