にアクセスする必要があるサービスアカウントがありますが/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マスクは、標準グループ権限とどのように関連していますか?