[systemd-devel] Avoid polkit queries from systemctl in package maintainer scripts/when running as root?

Martin Pitt martin.pitt at ubuntu.com
Mon Apr 4 15:31:23 UTC 2016


Hello all,

a recent (mostly cosmetical) bug report [1] made me aware that we
currently query polkit for a lot of systemctl
enable/daemon-reload/etc. calls from package maintainer scripts. At
least in Debian, installing a package with a .service usually does
something like "systemctl enable/start foo", and installing a package
with a SysV script runs "systemctl daemon-reload" to pick up the new
init script.

In all those cases systemctl is guaranteed to run as root, and any
potential interactive PK prompt would be totally unexpected -- because
of root, and because package installation is supposed to be
non-interactive and not hang. So this introduces a potentially
unreliable moving part and also assumes that polkit actually works all
the time (cf. package upgrades).

My initial response was to propose some patches that all "systemctl"
commands from maintainer scripts will be done with --no-ask-password.
However, this would require rebuilding a lot of packages, and I would
guess this affects other distribuions in some way too?

A more upstreamable approach would be to not query polkit at all if
geteuid() == 0. Is there any legit scenario where root would be denied
running systemctl directly, but a polkit rule would allow it
nevertheless? In such a scenario, is it really legit to get an
interactive PK auth prompt for something like "systemctl enable foo"
when installing package foo?

Thanks for opinions,

Martin

[1] https://launchpad.net/bugs/1565617

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160404/84b86677/attachment.sig>


More information about the systemd-devel mailing list