[systemd-devel] restart vs. stop/start

[Lennart Poettering]

On Sun, 22.05.16 16:18, Christian Boltz (systemd-devel at cboltz.de) wrote:

> I can add my usecase as another reason ;-)
> 
> I'm talking about AppArmor, where "stop" means unloading the profiles 
> from the kernel. The result is that all AppArmor confinement is removed 
> from all running processes.

Hmm, your apparmor service, does it actually have any processes
running during runtime? Is there actually any need to run it at
shutdown at all (i.e. why would you unload the apparmor policies when
powering off?)?

It appears to me, that you are trying to map something onto the
"service" concept, that probably shouldn't really be a service. As
someone who really doesn't know aa I'd probably suggest to have some
tool maybe called "aactl" that exposes the various verbs you want as a
UI, for example "load", "unload", ... And then, add one service to
systemd that is of Type=oneshot and RemainAfterExit=yes, and runs
"ExecStart=/usr/bin/aactl load". But do not misuse this as user-facing
concept, do not make it do anything on stop or even restart, but only
use it as a way of hooking aa into the early-boot process. Or in other
words: make users use "aactl reload" or so, to reload their policies,
and don't involve systemd in that, except for initial policy loading
during early boot.

Oh, and btw, I offered this before: we currently load SELinux, IMA and
SMACK policy when transitioning between the initrd and the host system
right from PID 1, before invoking any services, so that the policy is
applied to everything we start during normal operation. I'd be open to
doing the same for the AA policy. In that case you wouldn't even need
the hook service at all. None of the other MACs have that... Happy to
take a patch for that.

> "start" means loading the profiles and applying the confinement to _newly 
> started_ profiles.
> 
> This also means that _already running_ processes won't be (re)confined [1], 
> which translates a small typo done by the admin ("systemctl restart 
> apparmor" instead of "systemctl reload apparmor") to leaving lots of 
> processes unconfined and turns that accidential use of "restart" into a 
> security risk.

Quite frankly, "restart" is supposed to do the same for all system
services, but you try to redefine it within the scope of your specific
service, and I am pretty sure we shouldn't cover that in systemd, and
I also think this isn't particularly friendly to users to have
services that behave differently on "restart" than others.

Lennart

-- 
Lennart Poettering, Red Hat