Grafische Anwendung als root starten

Avoid running graphical applications as root if possible, see #Circumvent running graphical applications as root.

Circumvent running graphical applications as root

sudoedit

To edit files as root, use sudoedit.

GVFS

Access to privileged files and directories is possible through GVFS by specifying the Vorlage:Ic backend in the URI scheme[1][2], e.g.:

$ nautilus admin:///root/

or

$ gedit admin:///etc/fstab

Xorg

By default, and for security reasons, root will be unable to connect to a non-root user's X server. There are multiple ways of allowing root to do so however, if necessary.

The proper, recommended way to run GUI applications under X with elevated privileges is to create a Polkit policy, as shown in this forum post. This should however "only be used for legacy programs", as Vorlage:Man reminds. Applications should rather "defer the privileged operations to an auditable, self-contained, minimal piece of code that gets executed after doing a privilege escalation, and gets dropped when not needed"[3]. This may be the object of a bug report to the upstream project.

Punctual methods

These methods wrap the application in an elevation framework and drop the acquired privileges once it exits:

• Vorlage:Man (from Vorlage:Pkg)

$ kdesu application

• sudo (must be properly configured)

$ sudo application

• Vorlage:AUR (wrapper around su which will transfer your X credentials)

$ sux root application

Alternate methods

These methods will allow root to connect to a non-root user's X server, but present varying levels of security risks, especially if you run ssh. If you are behind a firewall, you may consider them to be safe enough for your requirements.

Xhost

Xhost can be used to temporarily allow root access.

Permanently allow root access

Method 1: Add the line

session         optional        pam_xauth.so

to both Vorlage:Ic and Vorlage:Ic. Then switch to your root user using Vorlage:Ic or Vorlage:Ic.

Method 2: Globally in Vorlage:Ic

Add the following line to Vorlage:Ic:

This will permanently allow root to connect to a non-root user's X server.

Or, merely specify a particular app:

# XAUTHORITY=/home/username/.Xauthority appname

where Vorlage:Ic is the name of the particular app. (e.g. kwrite)

Wayland

Trying to run a graphical application as root via su, sudo or pkexec in a Wayland session (e.g. GParted or Gedit), will fail with an error similar to this:

Before Wayland, running GUI applications with elevated privileges could be properly implemented by creating a Polkit policy, or more dangerously done by running the command in a terminal by prepending the command with Vorlage:Ic; but under (X)Wayland this does not work anymore as the default has been made to only allow the user who started the X server to connect clients to it (see the bug report and the upstream commits it refers to).

Avoid running graphical applications as root if possible, see #Circumvent running graphical applications as root.

A more versatile though more insecure workaround allows any graphical application to be run as root #Using xhost.

Using xhost

A more versatile —though much less secure— workaround is to use xhost to temporarily allow the root user to access the local user's X session[4]. To do so, execute the following command as the current (unprivileged) user:

$ xhost si:localuser:root

To remove this access after the application has been closed:

$ xhost -si:localuser:root

Using sudo -E

You can launch an application with:

$ sudo -E program

which preserves environment variables like WAYLAND_DISPLAY.

If you want the HOME environment variable to be set to the target user, use:

$ sudo -EH program

See Vorlage:Man.

Using pkexec

You can launch GUI an application with:

$ pkexec env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR=/run/user/0 program

which preserves the environment variable WAYLAND_DISPLAY.