Difference between revisions of "Running X apps as root"

From ArchWiki
Jump to: navigation, search
m (rm gap)
(update man page references, updated man page links (interactive))
(Tag: wiki-scripts)
 
(15 intermediate revisions by 6 users not shown)
Line 1: Line 1:
[[Category:X Server]]
+
[[Category:X server]]
 
[[ko:Running X apps as root]]
 
[[ko:Running X apps as root]]
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==
+
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 most secure methods are simple. They include:
+
{{Warning|1=All of the following methods have security implications that users should be aware of. As put by Emmanuele Bassi, a GNOME developper: "''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]}}
  
* kdesu (included with KDE)
+
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.
 +
 
 +
== Ponctual methods ==
 +
 
 +
Those methods wrap the application in an elevation framework and drop the acquired privileges once it exits:
 +
 
 +
* {{Pkg|kdesu}}
 
  $ kdesu ''name-of-app''
 
  $ kdesu ''name-of-app''
* gksu (included with GNOME)
+
See also [[Sudo#kdesu]].
 +
* [[Sudo#gksu|gksu]]
 +
{{Warning|1=''gksu'' has been deprecated since 2011[https://bugzilla.gnome.org//show_bug.cgi?id=772875#c5], and has not seen any update since 2014[https://www.archlinux.org/packages/?name=gksu].}}
 
  $ gksu ''name-of-app''
 
  $ gksu ''name-of-app''
* bashrun (in community)
+
See also [[Sudo#gksu]].
 +
* {{Pkg|bashrun}} (in community)
 
  $ bashrun --su ''name-of-app''
 
  $ bashrun --su ''name-of-app''
 
* [[sudo]] (must be installed and properly configured with <code>visudo</code>)
 
* [[sudo]] (must be installed and properly configured with <code>visudo</code>)
 
  $ sudo ''name-of-app''
 
  $ sudo ''name-of-app''
* {{pkg|sux}} (wrapper around su which will transfer your X credentials)
+
* {{AUR|sux}} (wrapper around su which will transfer your X credentials)
 
  $ sux root ''name-of-app''
 
  $ sux root ''name-of-app''
 
These are the preferred methods, because they automatically exit when the application exits, negating any security risks quite completely.
 
  
 
==Alternate methods==
 
==Alternate methods==
Line 23: Line 30:
 
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'''
+
=== Temporarily allow root access ===
  
:*xhost
+
See [[Xhost]].
$ xhost +
 
will temporarily allow root, or ''anyone'' to connect your X server. Likewise,
 
$ xhost -
 
will disallow this function afterward.  
 
  
Some users also use:
+
=== Permanently allow root access ===
$ xhost + localhost
 
(Your X server must be configured to listen to TCP connections for <code>xhost + localhost</code>  to work).
 
  
* '''Permanently allow root access'''
+
:'''Method 1''': Add the line
  
:*Globally in <code>/etc/profile</code>
+
<code>session        optional        pam_xauth.so</code>
 +
 
 +
to <code> /etc/pam.d/su </code> and <code>/etc/pam.d/su-l</code>. Then switch to your root user
 +
using 'su' or 'su -'.
 +
 
 +
:'''Method 2''': Globally in <code>/etc/profile</code>
 
Add the following to <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
Line 45: Line 51:
 
  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 ==
 +
If you are running wayland, you'll find that the fallback X server won't work when running programs as root. Try running <code>xhost +local:</code> first.

Latest revision as of 18:57, 9 September 2017

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.

Warning: All of the following methods have security implications that users should be aware of. As put by Emmanuele Bassi, a GNOME developper: "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]

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"[2]. This may be the object of a bug report to the upstream project.

Ponctual methods

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

$ kdesu name-of-app

See also Sudo#kdesu.

Warning: gksu has been deprecated since 2011[3], and has not seen any update since 2014[4].
$ gksu name-of-app

See also Sudo#gksu.

$ bashrun --su name-of-app
  • sudo (must be installed and properly configured with visudo)
$ sudo name-of-app
  • suxAUR (wrapper around su which will transfer your X credentials)
$ sux root name-of-app

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.

Temporarily allow root access

See Xhost.

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 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

If you are running wayland, you'll find that the fallback X server won't work when running programs as root. Try running xhost +local: first.