On Friday, April 11, 2014 03:14:31 AM Lennart Poettering wrote: > On Thu, 03.04.14 18:00, Colin Guthrie (gm...@colin.guthr.ie) wrote: > > Alternatively we can do "systemctl kill" in this case prior to uninstall > > and that will work (systemctl kill does not respect RefuseManualStop). > > Yeah, this is probably what I'd do. > > > Anyway, just wanted to discuss the best approach here. Perhaps the > > upstream unit could be tweaked? Perhaps RefuseManualStop is overkill? > > We added RefuseManualStop= justfor this. Don't remember the details > though, why this is a good thing though... Sounds like tpyicial audit > security theatre to me in retrospect... > > Steve, what's the precise reason auditd.service makes use of > RefuseManualStop=?
The reason is because we have to record who issued the shutdown request. The way that it worked prior to systemd is to use the service command which runs in the user's context. The user is identified by a field, auid, in the task struct in the kernel. They also have selinux subject lable on the process. When a signal is sent to the audit daemon, the kernel looks at the sending process and grabs the auid and selinux subject label from its task struct and saves it for the audit daemon to retrieve. When systemctl is used, systemd sends the term signal and the auid for systemd is -1 (meaning unset) which is normal and expected for a daemon. It also has the initrc_t subject label which is also normal for init, but clearly not the user. So, we really can't tell who issued the shutdown command. The "fix" is not allow the dbus path so that the shutdown occurs in the users context so the auid & selinux subject label are available. If you can think of a change to the spec file get the restart to occur in the user's context so that a yum update by an admin records the admin's auid & subject label, then I'd be happy to make the change. Thanks, -Steve _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
