Debian 12 AppArmor

[elcign]

I had to disable AppArmor for chrony to get this working on Debian 12. Can you please verify and fix if you agree? I may be out of my depth.

Here's what I had to run: aa-complain /etc/apparmor.d/usr.sbin.chronyd

[Frzk]

Hello @elcign, I understand your need. The issue I have is to decide whether dealing with apparmor belongs to this role or to an 'apparmor' one 🤔 For now, I'd much inclined to favor the latter. Any thoughts?

[elcign]

If you mean that you'd rather attempt to secure chrony's daemon with another role and simply configure chrony on this one, I'd agree.

Or maybe you could have a variable that allows us to run the current role without securing the daemon in case a future Debian upgrade breaks it again? I don't know enough about how this all works to know if that's possible.

In any case I otherwise really like the role, so I appreciate the work.

[njanzenfc]

I noticed this issue as well, the following changes in templates/systemd_override.conf.j2 fixed it for us:

- DynamicUser=true
- User=chrony
- Group=chrony
+ User=_chrony
+ Group=_chrony

After redeploying, executing systemctl daemon-reload and restarting chrony everything works fine. This works for us as we know the _chrony user is present and the correct permissions are set on all machines.

Maybe you could write a check to ensure the presence of the user _chrony in /etc/passwd and then apply an adjusted systemd_override. @Frzk

The apparmor issues occurs because the dynamic user id created by the systemd service doesn't match the user id for the chrony user in /etc/passwd