run systemd-sysv-install on the server side

[mbiebl]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

v232

Used distribution

Debian

In case of bug report: Expected behaviour you didn't see

Running systemctl enable as unprivileged user should show the polkit prompt, and after successful authentication, systemd-sysv-install should run with the necessary root privileges so it can change the configuration for a SysV/LSB service

In case of bug report: Unexpected behaviour you saw

$ systemctl enable apport
apport.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable apport
insserv: can not symlink(../init.d/apport, ../rc2.d/S01apport): Permission denied
insserv: can not symlink(../init.d/apport, ../rc3.d/S01apport): Permission denied
insserv: can not symlink(../init.d/apport, ../rc4.d/S01apport): Permission denied
insserv: can not symlink(../init.d/apport, ../rc5.d/S01apport): Permission denied
insserv: fopen(.depend.stop): Permission denied
update-rc.d: error: no runlevel symlinks to modify, aborting!

In case of bug report: Steps to reproduce the problem

Run systemctl enable for a SysV service as unprivileged user.

[poettering]

Humm, I am not sure we should really add any new code for that. SysV is legacy, and I doubt we need to support the SysV init scripts any better than they were supported on SysV init. I mean, there you didn't have polkit, and unprivileged access or anything either. The only way to enable them there was chkconfig/update-rc.d, and that required root.

We don't improve legacy/compat stuff beyond what the original version supported. If you want new stuff, just use native unit files, and your life will be better in a ton of other ways too.

[poettering]

that said, we should probably log explicitly about this and skip the callout when invoked with UID != 0

[mbiebl]

Under sysv, we didn't use polkit, so this wasn't really an issue there.
Keep in mind, that in Debian packages ship both native .service files legacy SysV init scripts and we use systemd-sysv-install to keep the state in sync. By allowing unprivileged users to manipulate the state of the native service file but not the sysv init script, those will get out-of-sync.

I don't think a UID != 0 check would be helpful, on the contrary.
If you are adamant to not add support for that on the server side, we could at least wrap the calls in systemd-sysv-install with pkexec, i.e. decide in systemd-sysv-install what to do if UID !=0.
This would be highly annoying, as you get multiple prompts (one for systemctl enable, one for pkexec update-rc.d and one for systemctl reload).

I still hope, we can move this to the server side to avoid this annoyance.

[fsateler]

SysV is legacy, and I doubt we need to support the SysV init scripts any better than they were supported on SysV init

I agree with the sentiment but I think this issue is of wider scope than this. Because enabling/disabling units via the bus has different results than via the cli, this makes bus users (like cockpit) less useful, as the world is still abundant in sysv-only services.

So, rather than framing this as adding more functionality to the sysv compat, I'd frame this as systemd being consistent when run on the command line versus the bus.

[keszybz]

I think we can reasonably say that this is never going to happen. We will not add any new support for sysvinit.