1

Running Ubuntu 16.04 in host, I have the following setup:

  • a user1, who performed a GUI login in host;
  • a user2, who is a sudoer and is logged in only through a text ssh connection (ssh user2@host).

I would like user2 to run an X application, for example xclock, on the user1 display. From user1 perspective, this must be the same as when user1 itself runs xclock.

The owner of the process xclock should be user2, because this is the user who launched it, but however this is not important.

Edit: I can use sudo, but I can not use user1 password, which is unknown to me.

How to accomplish this?

I read this answer and this answer, but they contain no direct examples about this. I also read about ~/.Xautority, MIT-MAGIC-COOKIE-1 and I obtained the list of cookies with xauth list, but wasn't able to use them.

I tried, from the prompt in the ssh connection (so, as user2):

$ env DISPLAY=:0 XAUTHORITY=/home/user1/.Xauthority xclock

but this causes the prompt to never return. Note that, being a sudoer, user2 is potentially able to read/copy/write the file .Xauthority in user1 home directory. The above commands, however, don't work even when user2 and user1 are the same.

BowPark
  • 4,895
  • Did you run sudo su or sudo bash before the xclock command? user2 may be a sudoer, but still needs to run sudo to get root privileges. – JigglyNaga Dec 14 '18 at 17:52
  • @JigglyNaga Neither of them, I ran the whole xclock line just as user2. – BowPark Dec 14 '18 at 18:16
  • It is the same, after trying with sudo bash and then the command. The prompt does not return. – BowPark Dec 14 '18 at 18:27
  • The prompt shouldn't return until xclock exits. Does xclock appear on user1's display? – JigglyNaga Dec 14 '18 at 18:33
  • @JigglyNaga You're right. However, in this case xclock doesn't appear. – BowPark Dec 14 '18 at 19:15
  • 1
    You must export the var and run xclock as user1. I can't test with your config but it's ok on OpenBSD from root user on debian : su -l user1 -c 'export DISPLAY=:0.0;XAUTHORITY=/home/user1/XAUTHORITY;xclock&' – ctac_ Dec 14 '18 at 20:22
  • @ctac_ Thank you for your test. su would require the user1 password, while instead I would like to use sudo from user2, so with user2 password. It works with (I guess it is a sort of equivalent to your su):

    sudo -u user1 DISPLAY=:0 xclock &

     – BowPark Dec 14 '18 at 21:58
  • @ctac_ If (after these considerations) you want to write an answer, I'll accept it. – BowPark Dec 14 '18 at 22:00

4 Answers4

3

Neither I am using sudo, ever, but the standard procedure to let another user on your display is to export the auth info with xauth(1), not muck by hand with ~/.Xauthority.

So, if user1 is the one logged in on the display, the guest (user2) should run the following commands:

user2$ export DISPLAY=:0
user2$ ssh user1@localhost "xauth extract - $DISPLAY" | xauth merge -
user2$ xclock

su could be used instead of ssh:

user2$ su - user1 -c "xauth extract - $DISPLAY" | xauth merge -
  • Thanks for all your suggestions. As I said in the comments to the questions (but I'll now edit the question to make it more readable), I would like to use sudo, but not to use the user1 password (I don't and shouldn't know it), which is required instead in your example. – BowPark Dec 15 '18 at 11:27
  • You can replace the ssh or su with sudo -u user1 xauth extract - $DISPLAY | .... –  Dec 15 '18 at 13:04
  • It doesn't work. I tried with sudo -u user1 -i xauth extract - $DISPLAY | ... and it works. – BowPark Dec 15 '18 at 15:17
  • @mosvy I am getting this error xauth: timeout in locking authority file /run/user/1000/gdm/Xauthority; xauth: (argv):1: unable to read any entries from file "(stdin)" when I run su secure -c "xauth extract - $DISPLAY" | xauth merge -. Here my current UID is 1000, and UID for secure is 1001. Can you please make suggestion? – Porcupine Mar 03 '21 at 13:05
  • @Porcupine Try with su - secure -c "... (notice the dash between su and secure). That should prevent su from passing down the XAUTHORITY environment variable, which would cause both the extracting and the merging xauth to work on the same file, which is not what was intended. –  Mar 04 '21 at 15:06
  • @mosvy Whenn I did $ su - secure -c "xauth extract - $DISPLAY" | xauth merge - I got: xauth: file /home/secure/.Xauthority does not exist No matches found, authority file "-" not written xauth: (argv):1: unable to read any entries from file "(stdin)" Also, echo $XAUTHORITY is blank for secure user. ` – Porcupine Mar 05 '21 at 11:40
  • I suggest you try giving the name of the xauth file explicitly via -f, instead of letting it guess it (wrong) via the user name and the XAUTHORITY envvar. Assuming that a) secure is the user logged into the display and its uid is 1001, try su - secure -c "xauth -f /run/user/1001/gdm/Xauthority extract - $DISPLAY" | xauth merge -. –  Mar 06 '21 at 19:02
  • Notice that --depending on your system (are you using Xwayland?)-- xauth & mit cookie authentication may not be used at all; in that case, su - secure -c 'DISPLAY=:0 xhost +si:localuser:your_user_name' should give you access to the display :0 if user secure is already logged in on that display. –  Mar 06 '21 at 19:16
1

To connect to someone else's X11 session, you'll need the correct value for the DISPLAY environment variable and the contents of the other user's ~/.Xauthority file.

If user1 has logged in locally, their DISPLAY variable setting is almost always :0.0, as this is the first local X11 display.

As user2, you could do this:

export DISPLAY=':0.0'
sudo cp ~user1/.Xauthority $TMP/user1_Xauthority
sudo chown user2 $TMP/user1_Xauthority
export XAUTHORITY=$TMP/user1_Xauthority
xclock &

Since DISPLAY=':0.0' tells the X11 applications to connect to a local display through an UNIX socket located in /tmp/.X11-unix/X0, these commands must be run on the same host that has the physical display.

Historically, the X11 protocol was originally designed to also allow connecting to the display over the network, using TCP port (6000 + display number), but this turned out to be not secure, and on modern Linux/Unix systems is usually disabled by default, so using something like export DISPLAY=remotehost:0.0 to push your X11 application's output to the display connected to remotehost will not work unless specifically enabled (and enabling that is usually a bad idea).

telcoM
  • 96,466
  • Thanks for all your considerations, which are more clarifying about this. I tried as suggested, but it didn't work: No protocol specified Error: Can't open display: :0.0. – BowPark Dec 15 '18 at 11:23
  • ~user1/.Xauthority has permissions 600 and the owner is user1. When copied with sudo cp ~user1/.Xauthority $TMP/user1_Xauthority, the newly created file $TMP/user1_Xauthority has the same permissions, but the owner is root. So, at least to me, this example works only if chown user2 $TMP/user1_Xauthority is performed before launching xclock. – BowPark Dec 15 '18 at 11:39
  • Oops, that's true. My mistake. – telcoM Dec 15 '18 at 11:51
1

All the considerations in all the answers are useful, but none of the suggested commands is the solution asked for. Just for the sake of clarity, I try to provide it here.

The best approach seems to be the mosvy one, also because of the very restrictive permissions of the file ~user1/.Xauthority.

The number of the active DISPLAY, used by user1, must be obtained first. It is available, for example, from the output of who and it is usually :0.

If user2 is a sudoer, only his password is required, not user1 password. From user2 prompt:

user2$ export DISPLAY=:0
user2$ sudo -u user1 -i xauth extract - $DISPLAY | xauth merge -
user2$ xclock

Or (acting as user1):

user2$ sudo -u user1 DISPLAY=:0 xclock &
BowPark
  • 4,895
0

I can't give a complete solution because i don't use sudo at all. You must export DISPLAY and XAUTHORITY before running xclock as user1.

su -l user1 -c 'export DISPLAY=:0.0;XAUTHORITY=/home/user1/XAUTHORITY;xclock&'

Note that is not a durable solution because DISPLAY and XAUTHORITY are not always the same.

ctac_
  • 1,960