I have a service account that requires access to /var/log/audit/audit.log and since this user shouldn't be part of the root group nor do I want to change the ownership or group of the file, I decided to implement file ACLs.
The issue is that when auditd rotates the file, the rotated file does not have the expected file ACL according to the man pages acl(5) and setfacl(1).
This is the file ACL for the parent directory, including the default 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::---
When auditd rotates the file the ACL becomes:
> 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::---
As you can see, the effective permissions is that the account is not allowed to do anything.
What leads me to believe something weird is happening is that when I create a file in that path as root manually, the following ACL is applied:
> 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::---
This ACL matches the documentation in acl(5) that says:
The new object inherits the default ACL of the containing directory as its access ACL.
The file ACL matches the default ACL of /var/log/audit.
What's happening?
