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.

  • bizdelnick@lemmy.ml
    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@lemmy.ml
            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.

              • bizdelnick@lemmy.ml
                21·
                7 months ago

                gksu and kdesu are unsupported for >10 years iirc, they were not more secure than sudo and that’s one of the reasons they were abandoned. I’ve never heard about sux. 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 via sudo or pkexec, 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.

                • Rustmilian@lemmy.worldEnglish
                  1·
                  7 months ago

                  gksu and kdesu are unsupported for >10 years iirc

                  I know.

                  they were not more secure than sudo

                  No, they were, barely, but they were, they were wrappers around sudo that provided “a more user-friendly and secure way to run graphical applications with elevated privileges, by handling environment variables and permissions better than using sudo directly.”
                  They’ve been deprecated in favor of pkexec.
                  sux is wrapper around su which transfers your X credentials, it sucks, don’t use it.

                  There’s no difference between running it via sudo or pkexec, however polkit provide additional protections to prevent running unsafe apps with elevated privileges.

                  pkexec literally uses Polkit and PAM under the hood.

                  pkexec runs the program in a “minimal known and safe environment” to avoid potential security issues like code injection through environment variables. pkexec also sets the PKEXEC_UID environment variable to the user ID of the process invoking it, providing more information about the context. pkexec is more secure than using sudo -i for running graphical applications, as it can prevent certain types of privilege escalation attacks. This increased security is largely due to the use of PolicyKit (Polkit) with pkexec. Polkit is a framework that provides a way to define and enforce fine-grained access control policies for privileged operations. With Polkit, the system administrator can define rules that determine which users or processes are allowed to perform specific privileged actions, like running a GUI application as root. This provides more granular control compared to the blanket root access granted by sudo.

                  PAM and GVFS are not “privilege elevation frameworks” whatever you mean by this.

                  You’re right, PAM is an authentication framework and GVFS is a whole other thing that leverages polkit and authentication agents. My bad.