Difference between revisions of "Running GUI applications as root"

From ArchWiki
Jump to: navigation, search
m (rm gap)
(update interlanguage links)
(Tag: wiki-scripts)
 
(45 intermediate revisions by 11 users not shown)
Line 1: Line 1:
[[Category:X Server]]
+
[[Category:Graphical user interfaces]]
[[ko:Running X apps as root]]
+
[[Category:Security]]
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, if it is necessary.
+
[[ja:root で X アプリケーションを起動]]
==The most secure methods==
+
[[ko:Running GUI applications as root]]
 +
{{Warning|1=All of the following methods have security implications that users should be aware of. As put by Emmanuele Bassi, a GNOME developer: "''there are no *real*, substantiated, technological reasons why anybody should run a GUI application as root. By running GUI applications as an admin user you're literally running millions of lines of code that have not been audited properly to run under elevated privileges; you're also running code that will touch files inside your $HOME and may change their ownership on the file system; connect, via IPC, to even more running code, etc. You're opening up a massive, gaping security hole [...].''"[https://bugzilla.gnome.org//show_bug.cgi?id=772875#c5]}}
  
The most secure methods are simple. They include:
+
Avoid running graphical applications as [[root]] if possible, see [[#Circumvent running graphical apps as root]].
  
* kdesu (included with KDE)
+
== Circumvent running graphical apps as root ==
$ kdesu ''name-of-app''
 
* gksu (included with GNOME)
 
$ gksu ''name-of-app''
 
* bashrun (in community)
 
$ bashrun --su ''name-of-app''
 
* [[sudo]] (must be installed and properly configured with <code>visudo</code>)
 
$ sudo ''name-of-app''
 
* {{pkg|sux}} (wrapper around su which will transfer your X credentials)
 
$ sux root ''name-of-app''
 
  
These are the preferred methods, because they automatically exit when the application exits, negating any security risks quite completely.
+
=== sudoedit ===
  
==Alternate methods==
+
To edit files as root, use [[sudoedit]].
 +
 
 +
===  GVFS ===
 +
 
 +
Access to privileged files and directories is possible through [[GVFS]] by specifying the {{ic|admin}} [https://wiki.gnome.org/Projects/gvfs/backends backend] in the URI scheme[https://bugzilla.redhat.com/show_bug.cgi?id=1274451#c27][https://bugzilla.gnome.org//show_bug.cgi?id=772875#c2], e.g.:
 +
 
 +
$ nautilus admin:///root/
 +
 
 +
or
 +
 
 +
$ gedit admin:///etc/fstab
 +
 
 +
{{Tip|1=This can also be done from the application location bar/file selector: e.g. in {{Pkg|nautilus}} or {{pkg|gedit}}, type {{ic|Ctrl+l}} and then prepend the {{ic|admin://}} scheme to the resource path. The same effect can be attained via the [https://wiki.gnome.org/Apps/Files?action=AttachFile&do=get&target=network.png Other locations] server address bar.}}
 +
 
 +
== 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 apps under X with elevated privileges is to create a [[Polkit]] policy, as shown in [https://bbs.archlinux.org/viewtopic.php?pid=999328#p999328 this forum post]. This should however "''only be used for legacy programs''", as {{man|1|pkexec}} 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''"[https://bugzilla.gnome.org//show_bug.cgi?id=772875#c5]. This may be the object of a bug report to the upstream project.
 +
 
 +
=== Punctual methods ===
 +
 
 +
Those methods wrap the application in an elevation framework and drop the acquired privileges once it exits:
 +
 
 +
* {{Pkg|kdesu}}, {{man|1|kdesu}}
 +
$ kdesu ''application''
 +
 
 +
* [[sudo]] (must be [[Sudo#Configuration|properly configured]])
 +
$ sudo ''application''
 +
 
 +
* {{AUR|sux}} (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.
 
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.
  
* '''Temporarily allow root access'''
+
==== Xhost ====
 +
 
 +
[[Xhost]] can be used to temporarily allow root access.
 +
 
 +
==== Permanently allow root access ====
  
:*xhost
+
:'''Method 1''': Add the line
$ xhost +
 
will temporarily allow root, or ''anyone'' to connect your X server. Likewise,
 
$ xhost -
 
will disallow this function afterward.
 
  
Some users also use:
+
  session        optional        pam_xauth.so
  $ xhost + localhost
 
(Your X server must be configured to listen to TCP connections for <code>xhost + localhost</code>  to work).
 
  
* '''Permanently allow root access'''
+
to {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}. Then switch to your root user
 +
using 'su' or 'su -'.
 +
 
 +
:'''Method 2''': Globally in {{ic|/etc/profile}}
 +
 
 +
Add the following line to {{ic|/etc/profile}}:
  
:*Globally in <code>/etc/profile</code>
 
Add the following to <code>/etc/profile</code>
 
 
  export XAUTHORITY=/home/non-root-usersname/.Xauthority
 
  export XAUTHORITY=/home/non-root-usersname/.Xauthority
 +
 
This will permanently allow root to connect to a non-root user's X server.
 
This will permanently allow root to connect to a non-root user's X server.
  
 
Or, merely specify a particular app:
 
Or, merely specify a particular app:
 +
 
  export XAUTHORITY=/home/usersname/.Xauthority kwrite
 
  export XAUTHORITY=/home/usersname/.Xauthority kwrite
 +
 
(to allow root to access kwrite, for instance.)
 
(to allow root to access kwrite, for instance.)
 +
 +
== Wayland ==
 +
 +
Trying to run a graphical application as root via [[su]], [[sudo]] or [[polkit|pkexec]] in a Wayland session (e.g. [[GParted]] or [[Gedit]]), will fail with an error similar to this:
 +
 +
{{bc|$ sudo gedit
 +
No protocol specified
 +
Unable to init server: Could not connect: Connection refused
 +
 +
(gedit:2349): Gtk-WARNING **: cannot open display: :0
 +
}}
 +
 +
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 {{ic|sudo}}; 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 [https://bugzilla.redhat.com/show_bug.cgi?id=1266771 bug report] and [https://cgit.freedesktop.org/xorg/xserver/commit/?id=c4534a3 the] [https://cgit.freedesktop.org/xorg/xserver/commit/?id=4b4b908 upstream] [https://cgit.freedesktop.org/xorg/xserver/commit/?id=76636ac commits] it refers to).
 +
 +
Avoid running graphical applications as root if possible, see [[#Circumvent running graphical apps as root]].
 +
 +
A more versatile though more insecure workaround allows any graphical application to be run as root [[#Using xhost]].
 +
 +
=== Using xhost ===
 +
 +
{{Expansion|Mention that xhost only works under XWayland.}}
 +
 +
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[https://bugzilla.redhat.com/show_bug.cgi?id=1274451#c64]. 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

Latest revision as of 08:38, 15 August 2018

Warning: All of the following methods have security implications that users should be aware of. As put by Emmanuele Bassi, a GNOME developer: "there are no *real*, substantiated, technological reasons why anybody should run a GUI application as root. By running GUI applications as an admin user you're literally running millions of lines of code that have not been audited properly to run under elevated privileges; you're also running code that will touch files inside your $HOME and may change their ownership on the file system; connect, via IPC, to even more running code, etc. You're opening up a massive, gaping security hole [...]."[1]

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

Circumvent running graphical apps as root

sudoedit

To edit files as root, use sudoedit.

GVFS

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

$ nautilus admin:///root/

or

$ gedit admin:///etc/fstab
Tip: This can also be done from the application location bar/file selector: e.g. in nautilus or gedit, type Ctrl+l and then prepend the admin:// scheme to the resource path. The same effect can be attained via the Other locations server address bar.

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 apps 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 pkexec(1) 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"[4]. This may be the object of a bug report to the upstream project.

Punctual methods

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

$ kdesu application
$ sudo application
  • suxAUR (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 /etc/pam.d/su and /etc/pam.d/su-l. Then switch to your root user using 'su' or 'su -'.

Method 2: Globally in /etc/profile

Add the following line to /etc/profile:

export XAUTHORITY=/home/non-root-usersname/.Xauthority

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

Or, merely specify a particular app:

export XAUTHORITY=/home/usersname/.Xauthority kwrite

(to allow root to access kwrite, for instance.)

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:

$ sudo gedit
No protocol specified
Unable to init server: Could not connect: Connection refused

(gedit:2349): Gtk-WARNING **: cannot open display: :0

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 sudo; 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 apps as root.

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

Using xhost

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Mention that xhost only works under XWayland. (Discuss in Talk:Running GUI applications as root#)

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[5]. 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