ServiceManager::install doesn't prompt for credentials on Linux

[nu11ptr]

On PopOs (Ubuntu clone) 22.04, uninstall, start, and stop all prompt for elevated credentials, however, install does not. It works fine when running my program with sudo, however. I wasn't sure if this is something the API itself triggered and was out of your control or something your library was triggering (I admit I didn't check your source), so I thought I would file a bug report just in case.

Without sudo, install immediately reports:

Error: Permission denied (os error 13)

[chipsenkbeil]

@nu11ptr which service manager are you using? Systemd?

[nu11ptr]

Yes, sorry....Systemd

[nu11ptr]

It looks like running systemctl is what triggers this (verified running this manually on my system triggers the popup box). For everything but install this is pretty much done immediately, but for install, a bunch of file creation I believe is done first which likely needs root itself. Not sure how this could really be fixed other than to do some sort of bogus systemctl call first perhaps? Also not sure how specific this is to my exact system or how many other Linux distros also trigger on this command.

[chipsenkbeil]

@nu11ptr, when you did the install with this library, did you configure it with user set to true? Systemd is one of two service managers, the other being launchd, that support user-level services that don't require root access.

As for being able to start/stop/etc, if you aren't running as user, then my guess is your account as permission to manager some root-level services similar to an account in the wheel group. But if you are setting user to true, then I'm not sure why it still needs root access.

[nu11ptr]

No, this is for a system level install, but I think you are misunderstanding. I may not be explaining it well.

My distro (and many distros I suspect) pop up a "privilege escalation box" when I execute systemctl which I assume changes the process to root similar to sudo etc (Not sure tbh how it works exactly, but similar to that always hated Windows UAC popup). Since three of your actions simply do a systemctl command and that's it, it pops up the box, I accept and those three actions work.... WITHOUT sudo, wheel, or any other privileged account.

Onto the issue. Technically, your library is doing nothing wrong, however, your install action does systemctl LAST, but does other privileged commands BEFORE running it, and these commands do NOT trigger the popup. Due to this, it simply fails with permission denied. What I was suggesting as a possible change is to issue a "bogus" systemctl FIRST (--help?) in your install action to force the popup giving privilege (maybe?) to the rest of the sequence. Tbh, this might only give privs to the systemctl command so it might not work, but thought it might be something to try. In fact, the more I think on this and as I write it out, I'm nearly convinced it won't work - pretty sure that popup would only grant root-like power to systemctl. Would make an interesting experiment, but don't think my idea is likely to work.

[chipsenkbeil]

Okay, that makes sense, thanks for sharing! Is there a specific process on linux that is controlling the UAC-like experience and permission granting? Wondering if there's a way to tap into the session. If we knew what it was, we could possibly add a check if that exists and is needed, and trigger the dialog ourselves if we're able to grant a script or something permission to execute. Just don't know anything about it.

[nu11ptr]

Tbh, same here. I know nothing about it. It just caught me off guard when 3 of 4 ops triggered it but the 4th didn't. Now that I see why. It would be neat to trigger it, but just don't know how either or even what the feature is called.

[chipsenkbeil]

Can you share a screenshot of the dialog?

[nu11ptr]

[nu11ptr]

I typed "systemctl start test" on my PopOS 22.04 (Ubuntu derivative) box to get that