Use polkit rather than sudo

[zefr0x]

When looking in some Linux distributions we can see that there are very few packages depending in sudo (nearly all of those optionally depending on it), while most of them especially GUI ones depends on polkit for running things as super user or another user.

In ArchLinux we have 19 packages depending in sudo while 89 depedning in polkit.

https://archlinux.org/packages/core/x86_64/sudo/

https://archlinux.org/packages/extra/x86_64/polkit/

In Gentoo we have 25 packages depending in sudo while 115 depedning in polkit.

https://packages.gentoo.org/packages/app-admin/sudo/reverse-dependencies

https://packages.gentoo.org/packages/sys-auth/polkit/reverse-dependencies

---

The main reasons are:

1. We have more control on privileges using polkit than sudo. We can restrict privileges to our needs, while using sudo we will get the privileges for every thing without restrictions.
2. Inside a desktop environment polkit is integrated to show a GUI prompt to enter your password, while sudo require a terminal to enter your password. (We will have the ability to run PINCE as a normal desktop application)

---

Examples of applications using polkit:

• GameConqueror (Memory scanner like PINCE)
• GParted
• Flatpak
• Hyprland

---

Related issues:

• doas support #112

[korcankaraokcu]

Yeah, polkit was mentioned in the past, it could be a nice addition. I'm not working actively on pince right now but I can try to implement it when I come back. Leaving the issue open for now

[authorisation]

I was having issues with gdb not being to initialize, turns out this was because I do not have sudo installed. Any reason why there is no exception printed for this in the terminal? Took me some fiddling to figure out.

[korcankaraokcu]

Any reason why there is no exception printed for this in the terminal?

All of distros we support use sudo that's why. You also don't need sudo specifically for the AppImage binary, any sudo equivalent that allows you to run a program as root will work. That "use sudo" message at the startup is just a recommendation since that's what most of the distros use

I'm not against the sudo alternatives but I just don't see it as important as the other features or improvements. I usually spend my free time on other issues. So, any PRs are welcome on this issue

[Twig6943]

Any updates on this? (this is the only program I run through terminal)

[brkzlr]

No updates. If there are any, there would be comments or issue would be closed.

[korcankaraokcu]

@Twig6943 Please stop spamming "Any updates?" to issues unless you have something useful to say, or even better, a proper PR

[Twig6943]

@Twig6943 Please stop spamming "Any updates?" to issues unless you have something useful to say, or even better, a proper PR

sorry, won't happen again

[gagero]

Where is the check for the UID done? It should be quite easy to replace that with polkit. Would anything else still need doing?

[brkzlr]

We also use sudo for gdb internally through pexpect (inside debugcore) so it's not just simply a matter of replacing the UID check.

The first one is done in PINCE.sh if you want to tackle it.

[gagero]

Hmm, polkit provides a dbus API, could that be used to authenticate both processes?

[brkzlr]

Possibly, I didn't look into it much as we were busy with other more important features.

Give it a try and shoot us a PR if you want to. Just make sure it doesn't break gdb functionality or the keyboard package which also requires root privileges to my knowledge.

Make sure to also modify the AppImage packager that is in ci/package.sh as that also uses sudo and will need polkit changes.

There might be a couple of other places that sudo is required but I'm not 100% sure.

[gagero]

Sure, I'll take a crack at it.

[gagero]

I've looked at it, and I don't think using polkit would be possible in a way that satisfies everyone. There are issues with the environment being deleted (which is mostly cosmetic, but still), and authenticating multiple processes would require a daemon and/or installing a bunch of files into /etc/. I certainly haven't become an expert in either polkit, or dbus in these few hours, so correct me if I'm wrong.

[brkzlr]

Yeah, that's what I imagined the issues would be. It's not really an easy task, given the way PINCE works, especially with gdb.

This was kinda placed on the backburner for a bit given the low priority and it might be made easier when we tackle the more important stuff, such as replacing gdb with lldb.
If we'll go ahead with this move, we could convert everything into a library and not have to spawn subprocesses anymore which would help a lot with the polkit transition.

[gagero]

Now that I think about it, it's perfectly possible that child processes inherit the authorization of its parent. We would still need to find a way to actually perform the authorization, but that might not be a huge issue. I'll need to test that, but if that is the case, then the only "damage" would be cosmetic.

[brkzlr]

What are you exactly referring to when saying "cosmetic"?

[gagero]

Environment variables still wouldn't be preserved, but you can preserve some individually using env, meaning that if you preserve basic things like PATH, you'd only lose themes.

[brkzlr]

We will need to preserve themes sadly, it won't be acceptable to lose any functionality that is currently present with sudo.

We'll also have to make sure that PINCE still uses the user's local .config folder where we store some settings. Without the environment preservation we do with sudo, those would be written to root's home (and also ignore user's own DE settings such as themes and such).

[gagero]

User-local .config should be more than possible, as I figure we would need to modify PINCE.sh anyway and could get it from that. I know GTK uses a set of environment variables to manage its themes, but I don't know what QT does. If it's a similar mechanism, you could very well preserve the theme as well.