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.

  • Rustmilian@lemmy.worldEnglish
    12·
    7 months ago

    No. It’s ”you probably shouldn’t run them with sudo” , many GUIs need root for certain tasks. I recommend using pkexec instead of sudo, you can add it to the .desktop file and when you launch the application it’ll give you a GUI authentication prompt.

    • bizdelnick
      13·
      7 months ago

      Probably? They won’t run with sudo normally (in xorg at least). And only those explicitly allowed to be run with pkexec by maintainers will do. Of course it is possible to evade this restriction, but you definitely should not.

      • Rustmilian@lemmy.worldEnglish
        4·
        7 months ago

        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. pkexec leverages PAM & Polkit and is intended for GUIs.

        • bizdelnick
          12·
          7 months ago

          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.

              • Rustmilian@lemmy.worldEnglish
                1·
                7 months ago

                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.

                • bizdelnick
                  1·
                  7 months ago

                  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.

                  • Rustmilian@lemmy.worldEnglish
                    01·
                    7 months ago

                    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 options gksudo/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.