26

I am trying to use an alternate user (non-admin) to execute graphical software on my system. This alternate user has been named and given a UID and GID to match a remote system user of the same name. The UID is 500 so I believe that makes the user a 'non-login' user.

Starting from Ubuntu logged into my main account, I open a terminal and su to the alternate user. I then attempt to execute the command to start the application and receive 'No protocol specified'.

Is this because of the UID<1000, because of the su or because of the non-admin of the user? How can I get this user to execute the application with a GUI?

Improve this question

10 Answers 10

Active Oldest Votes
21

The problem is not occurring because of the UID of the user. 500 is just fine as a UID, and that UID doesn't make it a 'non-login' user except in the eyes of the default settings of some few display managers.

The error message No protocol specified sounds like an application-specific error message, and an unhelpful one at that, but I am going to guess that the error is that the application is unable to contact your X11 display because it does not have permission to do so because it's running as a different user. Applications need a "magic cookie" (secret token) in order to talk to the X11 server so that other processes on the system running under other users cannot intrude on your display, create windows, and snoop your keystrokes. The other system user does not have access to this magic cookie because the permissions are set so that it is only accessible to the user who started the desktop environment (which is as it should be).

Try this, running as your original user, to copy the X11 cookie to the other account:

su - <otheruser> -c "unset XAUTHORITY; xauth add $(xauth list)"

then run your application. You may also need to unset XAUTHORITY in that shell too. That command extracts the magic cookie (xauth list) from your main user and adds it (xauth add) to where the other user can get it.

Improve this answer
7
  • Bizarrely, using your quoted command gives 'su: must be run from a terminal'. But it is in a terminal... – J Collins Jun 15 '15 at 9:46
  • 1
    @JCollins try xauth list >/tmp/xa.$$; su - <otheruser> -c "unset XAUTHORITY; xargs xauth add </tmp/xa.$$"; rm -f /tmp/xa.$$ but be aware there's a horrible race condition in there. – roaima Jun 15 '15 at 9:54
  • 1
    @JCollins oops, yeah, that would be a problem if su wants to ask for a password. Try this new command. – Celada Jun 15 '15 at 10:06
  • @Celada, gold, worked a treat. Could you have a go at detailing what that command is doing and how? And maybe explaining why the original incarnation did not? – J Collins Jun 15 '15 at 10:16
  • 2
    @JCollins you'll have to redo it each time after you log out and log in because a brand new magic cookie gets generated each time. That's normal, it's part of the security model. – Celada Jun 16 '15 at 2:21
18

In my case the new display server protocol wayland was the problem,

just do xhost + local: then other users (e.g. root) are allowed to run programs in your session, network connections however will not be allowed.

If you want to allow clients from any host, you can use xhost + without specifying any host at all. This is however unsafe, it would be better to just specify the host(s) for which you want to grant access to your session.

Improve this answer
4
  • 1
    In my case xhost + was sufficient enough – danger89 Apr 24 '18 at 11:32
  • 1
    @danger89 while this does work it allows any host to connect to your session if you have no firewall rules to prevent remote access (Not every distribution has firewall rules which deny all incoming requests e.g. ubuntu does not have preconfigured rules to prevent access to servers like samba or apache which the user might want to install) so for new linux users this could become a problem. Personally I would limit the access just to be on the save side – MADforFUNandHappy Jan 2 '19 at 18:13
  • This worked for me... but the problem is, I already ran the program before as su. Why, all of a sudden it stopped working without this inconvenience? – Miguel Angelo May 28 '20 at 19:55
  • 1
    Finally got around to updating to Wayland, thank you! – slf Feb 24 at 17:03
7

Suppose you want to brute force get yourself a connection with X...

Lets assume you are already running your commands on the server (where X runs), otherwise get that to work first and then use 'ssh -X user@server' from the client afterwards ;).

There might be several ways to run the xauth commands, for example, you might be using 'sudo', but that might lose or change environment variables. The following environment variables need to be preserved: DISPLAY and XAUTHORITY. To test if that is the case you could run 'echo $XAUTHORITY' in the same way you run your commands, but make sure you aren't expanding the environment variables before you run those commands. For example, try: sudo bash -c 'echo "$XAUTHORITY"' to see what XAUTHORITY really is after you run your sudo (if it disappears you might need to add something to your sudoers file, see elsewhere).

Eventually, run the following command as the user that you want to get access with, on the server:

xauth info

This will show the 'Authority file' that will be used (/root/.Xauthority by default, for root, or something like /home/theuser/.Xauthority). If it shows the correct .Xauthority file then you don't have to worry about the XAUTHORITY environment variable actually (actually, I wouldn't know when it wouldn't, except if you want to manipulate a non-standard place of that file).

Remove that file (if it even exists):

rm /root/.Xauthority

Replace /root/.Xauthority with the correct XAUTHORITY file for your case.

Recreate it, but empty (this is needed for a lot of commands):

touch /root/.Xauthority

At this point you'll get the No protocol specified error, even if you got Invalid MIT-MAGIC-COOKIE-1 before. Find the authority file that the X server is using at the moment:

ps aux | grep Xorg

This should show something like:

root 1153 0.0 1.0 149560 44464 tty7 Ss+ dec02 0:00 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711} -background none -noreset -displayfd 17 vt7

The file name after -auth is what you need in the next command. Run this as root:

sudo xauth -f '/var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711}' list

That lists a 32 digit hexadecimal key. For example the output could be:

hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

Use that to generate your .Xauthority file (as user who needs to login again):

xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

replace 'c0eaf749aa252101a0f57d5087089db7' with what was returned by the list command for you. Now your .Xauthority should be size 51 bytes and you can connect to the X server (again).

Improve this answer
1
  • There is no thread, this is a Q&A site, not a forum – Anthon Dec 2 '16 at 23:29
4

Try something like that

$ export LOGIN_USER="Math"
$ su - $LOGIN_USER
$ sudo xhost local:$LOGIN_USER &>/dev/null

source

Ps: the accepted answer not worked for me

Improve this answer
2

Just type this in your terminal xhost +SI:localuser:root after that you type export DISPLAY=:0.0 then try again

Improve this answer
1
  • This ^ works but I have to run this command after evey reboot on Ubuntu 20. No big deal but a little bit to remember. Adding this line to my current user ~/.bashrc file fixes it for me: export XAUTHORITY=~/.Xauthority The .Xauthority file sets the magic cookie params needed to open apps as root with xfce on Ubuntu 20. – Peter Drinnan Dec 27 '20 at 1:05
1

I had this error "No protocol specified" when I started an instance of Selenium 3.3.1 from an upstart script and then used the Chrome driver in Selenium. Selenium ran as the same user as X11, and DISPLAY shell environment variable was set correctly. What is interesting is that this error did not happen when I used the Firefox driver. Setting XAUTHORITY shell environment variable inside the upstart script to point to the value of $XAUTHORITY of the active X11 user fixed the error for the Chrome driver.

On a side note, the error "No protocol specified" was thoroughly buried by Chrome/Chrome driver and was by no means easy to find. I noticed that Chrome kept creating directories in the pattern of /tmp/.org.chromium.Chromium.*, but they were quickly disappearing. I managed to notice that they contained a file chrome_debug.log which had a message "Cannot open display". I figured this was rather strange since I have verified that the Selenium process had the correct DISPLAY in /proc/$pid/environ and examined the output of strace on the Selenium process more thoroughly, which revealed "No protocol specified" leading me eventually to this question.

This error can be reproduced by unsetting XAUTHORITY and trying to run some X11 client. For example:

$ XAUTHORITY= xeyes
No protocol specified
Error: Can't open display: :0.0
Improve this answer
0

This was simple. The problem happens when you are in root sate and want to use the gksu Just exit the root state and try again

Improve this answer
0

Using clues in the accepted answers, I was able to solve the issue differently:

  1. Locate the Xauth file in the account that works (Xauth1)
  2. Locate the Xauth file in the account that doesn't (Xauth2)
  3. Copy Xauth1 to Xauth2
  4. Change the permissions of Xauth2

In code:

root@45c4933a8f1a:~# xauth info
Authority file:       /headless/.Xauthority
<snip>
root@45c4933a8f1a:~# su OtherUser
OtherUser@45c4933a8f1a:/headless$ xauth info
Authority file:       /home/OtherUser/.Xauthority
<snip>
OtherUser@45c4933a8f1a:/headless$ exit
exit
root@45c4933a8f1a:~# cp /headless/.Xauthority /home/OtherUser/.Xauthority 
root@45c4933a8f1a:~# chown OtherUser:OtherUser /home/OtherUser/.Xauthority
root@45c4933a8f1a:~# su OtherUser
Improve this answer
0

Let says you try to access to GUI as user2 (normal user), then You need to load installation UI as user2.

Try to following this:

Login as root:

sudo su

Test the x server:

xclock

If you can see a clock running, that's good to go, now try run this:

xhost

The result should like this:

xhost SI:localuser:tri
# tri is my user name

Now let user2 access xhost

xhost +SI:localuser:user2

now try to login again to user2 and try to open any of GUI program.

Improve this answer
0

To do all of this at once, 

su -c 'cat $XAUTHORITY' $(logname) > ~/.Xauthority && XAUTHORITY=~/.Xauthority

Type in the login user's password when asked.

Explanation

Building off tjb's answer, xauth info may not work (X11). When I tried this on the other user I received the error

xauth:  timeout in locking authority file /path/to/Xauthority

You may run echo $XAUTHORITY on user2 (one that doesn't work) to see user2's current authority file. User2 may not have proper access to this file so you can change it to something else (Ex: /home/user2/.Xauthority) or edit the files permissions. Changing the file as to not risk security issues:

XAUTHORITY=/home/user2/.Xauthority

and then follow the rest of tjb's answer.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.