Why can't I run GUI apps as root: "No protocol specified"?

Question

I installed Debian onto my machine last night. Now, I don't understand why I can't run GUI apps from a terminal when running as root.

For example:

sudo -i
glxgears

Generates the following output:

No protocol specified
Error: couldn't open display :0

But when I first open the terminal I can run glxgears from the user account. It's only after I do sudo -i that the problem crops up. This happens for any GUI app that I try to run.

I think it's probably related to X11, but I'm not sure.

http://stackoverflow.com/a/20612084
this worked perfectly for me. — , Oct 20 '14 at 09:42
About Wayland, just in case: Arch Wiki, "sudo with graphical apps doesn't work on wayland ". — Alexey, May 08 '19 at 13:25
@Alexey: The ArchWiki also contains a workaround using xhost. I tried running LinSSID and sparrow-wifi on Sway (Wayland) which worked after executing xhost +si:localuser:root, discussion here. — Matthias Braun, Mar 23 '22 at 13:25

score 66 · Accepted Answer · answered Mar 09 '14 at 09:17

66

Accessing the X server requires two things:

The $DISPLAY variable pointing to the correct display (usually :0)
Proper authentication information

The authentication information can be explicitly specified via $XAUTHORITY, and defaults to ~/.Xauthority otherwise.

If $DISPLAY and $XAUTHORITY is set for your user, sudo will set them for the new shell, too, and everything should work fine.

If they are not set, they will probably default to the wrong values and you cannot start and X applications.

In Debian $XAUTHORITY is usually not set explicitly. Just add

export XAUTHORITY=~/.Xauthority

to your .bashrc or explicitly say XAUTHORITY=~/.Xauthority sudo ... and everything should work.

You can also use xauth list to check whether proper authentication information are available.

answered Mar 09 '14 at 09:17

michas

21,510

5

xauth info shows path to authority file – Tomas Tomecek Apr 07 '15 at 07:11
4

xhost + fixed my problem – Melroy van den Berg Apr 24 '18 at 11:31
6

Be aware that xhost + completely deactivates authentication and allows everyone to access all application on your screen... – michas Apr 24 '18 at 14:14
1

for debian, do I type the XAUTHORITY export as root? because it's not working on deb10? I login with sudo su – marinara Mar 26 '19 at 21:22
@marinara use sudo -i instead of sudo su -. – michas Mar 26 '19 at 21:28
1

Now that Debian 10 (Buster) is out, how do you do this with wayland? – David Cowden Jul 18 '19 at 06:22
4

xhost +si:localuser:root seems to work similar. – David Cowden Jul 18 '19 at 06:29
On Ubuntu 18, I had to export XAUTHORITY=/run/user/1000/gdm/Xauthority – Seff Aug 23 '20 at 20:59
1

if anyone came here having issues with xrdp, just keep in mind that only the user you logged in with has the rights to start X apps. so e.g. your default ubuntu user is logged in, you cannot start GUI apps as root user.... – Flo Nov 05 '22 at 22:01

score 37 · Answer 2 · edited Apr 06 '19 at 01:23

37

I had the same question as you but for a normal user. Let's say I want to start firefox using the user account foo. I'm logged in as bar:

[bar@localhost ~]$ sudo -u foo -H firefox

Sadly that command failed with the same error as in the question (i.e. no protocol specified & cannot open display)

My solution was to simply add the user foo to the list of authorised access to the X server.

xhost si:localuser:foo

And that was it, I was then able to launch Firefox (and other X application) using sudo and the user foo.

Background: On X Window, there is a client/server architecture. When you launch an application you request the X server authorisation to display it. By default once you open a session (you graphically login), you (your user) are obviously allowed to commmunicate with the server and display applications. Other users do not have this permission unless you specify it. xhost is a tool to manipulate the list of permissions. The si indicates that the rule is server side and it authorise the local user foo to display applications. X Window is very powerful in this regard and you can display remote applications locally by playing with the DISPLAY environment variable and xhost (but not limited to them). In older times, when people typed xhost + and implicitely allowed everyone to use their X session, it was possible to display application on their screen for pranks ;-) not so much nowadays as people are less and less using X Window client/server architecture (at least for what I observe in the past 10 yers).

PS: I did this in order to launch Firefox in a kind of "jail" (to avoid a vulnerability like for pdf.js in the future). But I quickly found out that calling Firefox via sudo won't allow it to access audio nor the video hardware. But there is one guy which explain clearly how to activate video hardware acceleration and audio when calling Firefox via sudo. YMMV with these instructions, e.g. I still have a permission denied with audio but video is fine (tested on Fedora 22 with SELinux ON).

edited Apr 06 '19 at 01:23

Rui F Ribeiro

56,709
26
150
232

answered Aug 18 '15 at 12:49

Huygens

9,345

2

In my case foo was root, i.e. I had to run xhost si:localuser:root on Ubuntu 17.10. – Kalle Richter Dec 26 '17 at 02:12
Where do you add the xhost si:localhost<user> command? If no users are logged on, then no one has an X server available to give permission to. – cbcoutinho Mar 12 '18 at 20:44
1

@cbcoutinho The above use case is when someone is logged on and wants to run an XWindow application as someone else on the same host. If you explain your use case (what is the problem you would like to solve) then I can potentially help you. – Huygens Mar 12 '18 at 21:50
@Huygens I have a workstation for simulating fluids that is also equipped with a GPU. I render the visualizations with ParaView, a program built on vtk, usually on the workstation itself. ParaView also provides a secure headless client/server rendering model through ssh, which I would like to take advantage of remote instead of using VNC. Without logging into the workstation and executing xhost, I can't utilize the GPU. That means that I can't reboot the machine remotely and still have access to the GPU. – cbcoutinho Mar 13 '18 at 20:55
1

@cbcoutinho X Window is a client server architecture. When you connect via ssh, your local workstation becomes the client X Window. You could use the xhost with unsafe protocols like rlogin but not ssh. You need to instruct ssh to do it for you. Either use the -X or (better?) -Y flag on ssh, it will do the proper redirection. Of course you then need a local C Server. However with GPU and OpenGL, I am not sure where the rendering/compute happens perhaps it’s on the client side, not the server one. Could be tricky. – Huygens Mar 17 '18 at 22:58
@Huygens thanks for getting back to me. Regarding the rendering, ParaView has a server available with an offscreen rendering flag. Adding a dummy user with 'auto login' solved my problem – cbcoutinho Mar 17 '18 at 23:30
logged in as myself (as opposed to root), running xhost si:localuser:root worked for me – interestedparty333 Oct 16 '19 at 21:52

X Tian · Answer 3 · 2021-02-17T13:38:43.143

16

You can either

Specify the display to be used on the command line, by adding -display :0.0

or

Set up the environment variable in root's login script (one of .bashrc, .profile, .bash_profile ...).

export DISPLAY=:0.0

You can check whether it's set,

$ env |grep DISPLAY
DISPLAY=:0.0

To open up your display for all users from all hosts as your normal user you can do this with :

xhost +

Edit: Thanks and credit to @Toby Speight for his comment below for the more targeted suggestion, instead of opening it up for anybody.

xhost +si:localuser:root

edited Feb 17 '21 at 13:38

answered Mar 09 '14 at 09:14

X Tian

10,463

1

xhost + does work as a temporary measure before going in as sudo – Octopus Mar 09 '14 at 09:34
1

xhost + worked for me too, only that they forgot to mention we should run it from the authorizing user's terminal, not from a terminal under sudo su. – nyxee Jan 14 '17 at 08:28
1

perfect work like boom – Adiii Mar 26 '18 at 16:59
4

xhost +si:localuser:root would be a more targeted approach, better than allowing all users. – Toby Speight Feb 17 '21 at 07:45

score 6 · Answer 4 · answered Aug 31 '16 at 16:42

6

Given that you're on Debian, the simple and supported solution is to arrange for sudo to copy your X11 authorization credentials. pam_xauth is included in the libpam-modules package for exactly this purpose; to use it, you just need to add

session  optional  pam_xauth.so

to your /etc/pam.d/sudo file. You may also choose to add it to su, too. For full information, consult the pam_xauth man page, of course.

answered Aug 31 '16 at 16:42

Toby Speight

8,678

That is the most correct and underrated answer, since it also fixes a lot of other related issues and is a far cleaner solution. Putting session optional pam_xauth.so to /etc/pam.d/sudo and /etc/pam.d/su do work to launch softwares as root in the meantine pkexec (which was meant to replace gksu and gksudo) get its issues together when everything else said here failed. – X.LINK Feb 16 '21 at 22:40

score 3 · Answer 5 · edited Feb 17 '21 at 07:48

3

What helped me:

You can xauth generate :0 . trusted on the user side, which will generate a new MIT-MAGIC-COOKIE-1
Check the newly created Key with xauth list as user and root (they should be the same if your XAUTHORITY variable is pointing to the same file.
Voila, root will access any X application from terminal, but only temporarily.

To make it permanent, see @Huygens' answer!

edited Feb 17 '21 at 07:48

Toby Speight

8,678

answered Mar 12 '18 at 20:35

Timo

338

score 1 · Answer 6 · answered Jul 28 '19 at 09:46

The sudo command has a switch to preserve environment variables.

 -E, --preserve-env            preserve user environment when running command

So that you can run the command with -E switch. Example:

sudo -E wireshark

If you don't need to run privacy critical applications like web browsers, you will be better off adding -E switch with sudo. We cannot run Chrome or Firefox just by adding -E switch. Because many browsers have implemented protection against user space violations. @huygens's answer may have insights on this subject.

Note: Adding -E switch will not help if your user's environment does NOT have DISPLAY and XAUTHORITY already set correctly.

score 0 · Answer 7 · answered Jul 08 '22 at 05:01

0

I had the same issue and I did the following to use sudo:

You can use sudo with GUI using the options -sE, as follows:

sudo -sE GUI_CMD

For example, if you want to run nemo as root:

sudo -sE nemo

answered Jul 08 '22 at 05:01

AKMalkadi

341

score -3 · Answer 8 · edited Aug 31 '16 at 14:12

-3

use this command and it will work

sudo cp /home/user/.Xauthority .Xauthority

edited Aug 31 '16 at 14:12

HalosGhost

4,790

answered Aug 31 '16 at 13:55

user187508

1

2

This will give cp: cannot stat ‘/home/user/.Xauthority’: No such file or directory on any of the 10+ Debian based machines I have access to. – Anthon Aug 31 '16 at 14:29
1

This gives a little context (e.g., you silently expect some current directory) and you don't mention side effects like troubles when doing so in multiple X11 instances. I think this way is a bit hacky. – v6ak Mar 12 '18 at 20:44

Why can't I run GUI apps as root: "No protocol specified"?

8 Answers8

Linked