にアクセスする必要があるサービスアカウントがありますが/var/log/audit/audit.log、ユーザーがrootグループに属してはならず、ファイルの所有権やグループを変更したくないので、ファイルACLを実装することにしました。
問題は、auditdファイルを回転させるときのマンページacl(5)ですsetfacl(1)。
デフォルトのACLを含む親ディレクトリのファイルACLは次のとおりです。
> getfacl /var/log/audit
# file: var/log/audit
# owner: root
# group: root
user::rwx
user:srv_usr:r-x
group::---
mask::r-x
other::---
default:user::rwx
default:user:srv_usr:r--
default:group::---
default:mask::r--
default:other::---
auditdファイルが回転すると、ACLは次のようになります。
> getfacl /var/log/audit/audit.log
# file: var/log/audit/audit.log
# owner: root
# group: root
user::rw-
user:srv_usr:r-- #effective:---
group::---
mask::---
other::---
ご覧のとおり、有効な権限は、そのアカウントが何もできないことです。
奇妙なことが起こっていると信じるのは、そのパスにルートとしてファイルを手動で作成するときに次のACLが適用されることです。
> touch /var/log/audit/test
> getfacl /var/log/audit/test
# file: var/log/audit/test
# owner: root
# group: root
user::rw-
user:srv_usr:r--
group::---
mask::r--
other::---
このACLは文書の内容と一致しますacl(5)。
新しいオブジェクトは、インクルードディレクトリのデフォルトACLをアクセスACLに継承します。
ファイルACLはデフォルトのACLと一致します/var/log/audit。
どうしたの？
ベストアンサー1
問題は、Linux ACLがグループ権限ビットを使用してマスクを保存することです。
交換後は、 auditd が ACL をサポートせずにグループの権限を設定すると考えるため、グループの権限は削除されます。したがって、マスクは空であり（mask::---）、有効な権限も空です（#effective:---）。
この質問も参照してください。ファイルのACLマスクは、標準グループ権限とどのように関連していますか？