I found a (lengthy) guide to doing this but it is for gksu which is gone. I have to imagine there’s an easy way. I am running Ubuntu. There is no specific use case, it is just a feature I miss from windows.
EDIT: I always expect a degree of hostility and talking-down from the desktop Linux community, but the number of people in this thread telling me I am using my own computer that I bought with my own money in a way they don’t prefer while ignoring my question is just absurd and frankly should be deeply embarrassing for all of us. I have strongly defended the desktop Linux community for decades, but this experience has left a sour taste in my mouth.
Thank you to the few of you who tried to assist without judgement or assumptions.
Probably? They won’t run with
sudonormally (in xorg at least). And only those explicitly allowed to be run withpkexecby maintainers will do. Of course it is possible to evade this restriction, but you definitely should not.There’s plenty of GUI applications that’ll run just fine with sudo. For example BleachBit.
The commonality between these applications is when they were written, what (outdated) toolkit they use, etc.
Sudo is just not made for use with GUI and can possibly lead to bad behavior.
pkexecleverages PAM & Polkit and is intended for GUIs.It’s not when app was written. Wayland apps probably work with sudo, x11 don’t because sudo does not pass the
$DISPLAYenvironment variable. It’s a correct behavior of sudo because running x11 apps with root permission you create a security hole.sudo -EI know. Don’t do this. Read the manual.
Polkit was created in 2009 & PAM was created in 1995. GNU dates back to 1984, so… There’s still quite a handful of programs that are likely still maintained to this day that don’t properly take advantage of them or other auth systems made to be able to handle GUIs in a secure fashion. BleachBit being released in 2008, predates Polkit and afaik, bleachbit doesn’t leverage polkit by default, at least not on Arch.
Idk what is bleachbit. But I know that “auth systems” can’t “handle GUIs in a secure fashion”. The app itself can be secure or not. By default they are not secure if they provide a GUI running in privileged process.
gksu, kdesu, sux, & polkit. All of which are privilege elevation frameworks that can securely obtain the required privileges without running GUI applications directly as root. Granted you may need to configure PAM & Polkit’s policies to make them more secure.
The problem with sudo is that it runs the entire GUI application as Root; at least by default behavior. These frameworks are the proper way.
BleachBit is a cross-platform disk space cleaner that was based on Python, PyGTK, & GTK2 and then later ported to Python 3 & GTK3. BleachBit on Linux never prompts the user for authentication for operations requiring elevated privileges, it just fails with “permission denied”. Inturn you can use
sudo, or the by far more recommended and safer optionsgksudo/gksu&pkexec. In this case, a user can 100% make the mistake of using sudo, and while it’s not inherently problematic for this specific case, as we’ve already discussed it’s still risky.gksuandkdesuare unsupported for >10 years iirc, they were not more secure thansudoand that’s one of the reasons they were abandoned. I’ve never heard aboutsux. Polkit is a bit another thing that indeed replaced them, however it does not and can not separate GUI and non-GUI processes. The process itself has to fork, drop privileges and draw a GUI after that. There’s no difference between running it viasudoorpkexec, however polkit provide additional protections to prevent running unsafe apps with elevated privileges.PAM and GVFS are not “privilege elevation frameworks” whatever you mean by this.