Re:Systemd through the eyes of a musl distribution maintainer
by Nullabillity on Saturday January 06, 2024 @09:51AM
(#38891850)
Loginctl/per-user systemds are for managing interactive sessions. System services with User= is exactly the way you'd go for isolating background daemons.
Re:Systemd through the eyes of a musl distribution maintainer
by ptx on Saturday January 06, 2024 @11:03AM
(#38892503)
What if you want to let a non-root user manage the systemd unit for a particular service? Is there a better way than per-user systemd instances?
Re:Systemd through the eyes of a musl distribution maintainer
by acdha on Saturday January 06, 2024 @11:27AM
(#38892730)
Check example 3.4 here for a polkit policy allowing an arbitrary user to restart a single unit:
Re:Systemd through the eyes of a musl distribution maintainer
by twic on Saturday January 06, 2024 @12:52PM
(#38893478)
Does this let them modify the unit file, create units, create timers, etc?
User systemd allows that kind of complete self-service, and so lets you do application deployment and management without touching the root account, which is rather nice.
Re:Systemd through the eyes of a musl distribution maintainer
by BenjiWiebe on Saturday January 06, 2024 @07:36PM
(#38897108)
If they can edit a service that runs with more privileges than they have, that's a privilege escalation vulnerability.
Polkit lets a non-root user restart a root/privileged service without letting the non-root user gain privileges.
Re:Systemd through the eyes of a musl distribution maintainer
by chuckadams on Saturday January 06, 2024 @11:13AM
(#38892591)
chgrp, setfacl, sudo.conf ... lots of choices.
It's in a terrible way, too. Not sure it improved but I recall somebody once, at a company I worked at, trying to introduce per-unix-user systemd services (e.g. `graphite` user for running Graphite), and there were some atrocious steps required like `loginctl --enable-linger` and God knows what.
We moved to running everything systemd as root, it's easier (and you can specify which unixuser the actual systemd unit runs at, which is "close enough").