On Tue, 04 Jul 2017 at 20:33:54 +0000, Mariusz Wojcik wrote: > As far as I know, there > aren’t many services that need full root access (maybe for getting a low port > number).
systemd system units are basically a replacement for LSB (or sysvinit if you prefer) init scripts, which always run as full root, and can drop privileges themselves if they want to. Anything that runs with capabilities that trivially allow escalation to full root (such as CAP_SYS_ADMIN, CAP_FSETID, CAP_SETUID, CAP_SYS_MODULE, CAP_SYS_PTRACE) might as well be full root. Such processes are in the trusted computing base (TCB): it would be within their technical ability to break security policies. Using an unscientific sample consisting of the 12 system services starting with "a" or "b" on my Debian laptop: * apt-cacher-ng has a non-trivial User (systemd starts it unprivileged) * avahi-daemon starts as root to do some privileged setup, then drops privileges itself (this is a common pattern, dbus-daemon does this too) * alsa-{restore,state} don't necessarily need to be root, but do need hardware access, are not persistent (they are "oneshot" services run during boot and shutdown), and they are so simple that giving them privilege separation seems like a poor use of anyone's time * bluez runs as root but drops most capabilities * the rest run as "full" root and are in the TCB, and seem like they legitimately need it (for example atd and anacron have it as part of their "API" that they can be used to run arbitrary tasks, including being full root) I personally think the syntactic/semantic validity distinction here is not the least-astonishment behaviour, and my preferred resolution for this issue would be for User=7up or User="this name is silly!" to be exactly equivalent to specifying a User with a "normal" name that happens to be missing from `getent passwd` (in other words, the unit fails to start with exit status 217/USER). But you can tell I don't think this is critically important by the fact that I haven't written and proposed a patch with that behaviour. If this is more important to you than it is to me, a reasonable next step would be to put together that patch. S _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel