Re: [PATCH 7/7] audit: audit feature to set loginuid immutable

> > This sounds dangerous. Why would we want to allow this? Immutability was first introduced in kernel 3.3. It wasn't enabled in the kernel config for Fedora until some time much later. It is not present in any enterprise distro that I know of. Before systemd immutability was not possible. If an admin logged in and restarted the sshd daemon the daemon would be running as the admin's loginuid. When a new user tried to log in via ssh it would need to change the loginuid from the admin loginuid to their new loginuid. We had to give sshd CAP_AUDIT_CONTROL in order to switch the loginuid. (ALL loginuid changes required CAP_AUDIT_CONTROL) When systemd came out I added immutability. Since restarting sshd in a systemd world is done by init, which has no loginuid, and thus the new sshd would have no loginuid. Thus a user logging in would be able to set a new loginuid without any permissions. We learned that admins, for various reasons, really do want to be able to launch daemons by hand and not via init/systemd. In particular, we know of many people who launch containers by hand which allows some form of login (usually sshd). With the current loginuid immutable code those people are UNABLE to log in inside the container. This patch series allows a privileged task (one with CAP_AUDIT_CONTROL) the ability to unset their own loginuid. I allows behavior similar to the pre 3.3 kernels. Big different being that the privilege is needed in a helper to UNSET the loginuid, not in the network facing daemon (ssh) to SET the loginuid. The series also allows the 'unsetting' feature to be disabled and locked so it cannot ever be enabled.