Bug 1026648

auditd.service requests this by setting RefuseManualStop=yes.

"service auditd restart" works only because the audit package ships a script to tell "service" about a special way to do it (/usr/libexec/initscripts/legacy-actions/auditd/restart).

The reason for this weird handling of restart requests is that auditd is treated specially by the kernel: the credentials of a process that sends a killing signal to auditd are saved to the audit log. The audit developers do not want to see the credentials of PID 1 logged there. They want to see the loginuid of the user who initiated the action.

This is not an optimal solution, but a better one would require a kernel feature that does not currently exist.

Hmm interesting feature.

Is there is docs about such a differences between service and systemctl 
or
could it be created somewhere?
or
is it BUG/RFE to kernel (then change the component)?

Actually, the message coming out of systemd is not entirely helpful. Since its parsed the service file and seen the RefuseManualStop=yes, it could output something like: Unable to stop auditd.service, it's configured to refuse manual stops. This would at least point the user to the service rather than suspect something is wrong with systemd. It might prevent some bugs being filed under systemd.

That said, I suppose I could add something in the auditd man page that states it should be managed by the service command.

Petr, if you're curious, see bug 881057 for a previous discussion about the special stopping requirements of auditd.

Not only restart, I can't even stop auditd service.

root@vikas027:~# systemctl stop auditd
Failed to issue method call: Operation refused, unit auditd.service may be requested by dependency only.
root@vikas027:~#

In response to comment #10, this the correct behavior. When auditd gets a term signal, it has to query to see who sent the termination. You cannot get that over dbus, so we require it to be in the users context. Running the service command should do everything you need.

Systemctl start and status are about the only things you can safely use with auditd.

Nothing can be done without kernel dbus. As far as I know, work has stopped on that. I can defer this to RHEL Next if you want to keep it open. But audit is not the component where the work needs to be done. Its the kernel.

Just a reminder, there is nothing that can be done for this in the audit package. If any message cleanup is wanted, they come from systemctl and this bz needs to be reassigned or a new bz opened on systemd. If you want this to work correctly from systemctl, then it needs kdbus which is kernel work. Again not the audit package.

There is nothing we can do in systemd, we only have the dbus daemon available, which is not trusted by the audit, so we can't send some additional information about user that started systemctl through it. And since the kdbus is not happening there is no way we can fix it in rhel7.

I thikn what they are asking for is a more user friendly message than operation denied. What can't it say something like, "<service name> is configured to not allow systemctl to stop it. You might try stopping it with the service command or reviewing documentation associated with <service name>."

https://github.com/systemd/systemd/pull/5132

fix merged to upstream staging branch ->
https://github.com/lnykryn/systemd-rhel/commit/92ff0ade63ae85c6b6170af7b1209aaf37298ab1
-> post

Trying this on my RHEL 7.3 VM, `service auditd stop` just redirects to `systemctl stop auditd.service`, which fails because `RefuseManualStop=yes` - so I can't stop/start the auditd service at all now?

$ cat /etc/os-release


NAME="Red Hat Enterprise Linux Server"
VERSION="7.3 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="7.3"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.3:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.3
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.3"


$ service auditd stop

Redirecting to /bin/systemctl stop  auditd.service

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to manage system services or units.
Authenticating as: Vagrant (vagrant)
Password: 
==== AUTHENTICATION COMPLETE ===

Failed to stop auditd.service: Operation refused, unit auditd.service may be requested by dependency only.
See system logs and 'systemctl status auditd.service' for details.

Something seems wrong with your setup. Maybe you're missing the legacy files?
/usr/libexec/initscripts/legacy-actions/auditd/stop

(In reply to Steve Grubb from comment #32)
> Something seems wrong with your setup. Maybe you're missing the legacy files?
> /usr/libexec/initscripts/legacy-actions/auditd/stop

I'm completely willing to believe it's a problem with my setup - but it's not that problem ;) I have the legacy scripts and they work fine if I call them directly on the command line.


The context is that I have an Ansible task to restart auditd - and I'd like to work on RHEL7 systems in general - and ideally do things the 'correct' way - so I'm reluctant to call the legacy scripts directly from my ansible task. I'm currently using Ansible's `service` module (which then uses systemctl on RHEL7).

Maybe the correct thing to do *is* to use the legacy scripts directly on a RHEL7 system, as that's actually what would end up happening if `service auditd restart` was working properly, instead of redirecting to systemctl?

OK. I was under the impression that the only source for the service command came from the initscripts package. If that is not the case, then the new service command needs to support the legacy scripts or things will not work. You probably should open a new bz against whatever provides your service command to align it with how things _have_ to work. Its supposed to look for a match in the legacy scripts section and run it. If no match _then_ redirect to systemctl.

> I was under the impression that the only source for the service command came from the initscripts package.

Ansible has a module, that happens to be called `service`, that is used for restarting services in a cross-platform way. I just looked at it's [source code](https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/system/service.py), and for linux, if it can find systemd, then it'll use `systemctl` for everything; it doesn't check for the existence of any legacy scripts, and doesn't do anything RHEL specific. If it detects that a system is using systemd for init, then it'll use `systemctl` for service start/stop/etc... actions.

Now that I understand what's going on, I found that there's an open bug with Ansible for this: https://github.com/ansible/ansible/issues/22171

I'll add to it and reference this thread.

Thanks!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2297