Run X program in another user's display

Question

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.

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

score 3 · Answer 1 · 2021-03-04T15:04:03.853

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 -

edited Mar 04 '21 at 15:04

answered Dec 15 '18 at 07:23

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**](https://unix.stackexchange.com/questions/571101/xephyr-ac-dangerously/571152#comment1063234_571152); 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

telcoM · Answer 2 · 2018-12-15T11:52:02.453

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

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

score 0 · Answer 3 · answered Dec 15 '18 at 06:58

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.

BowPark · Answer 4 · 2018-12-15T17:32:09.767

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 &

Run X program in another user's display

4 Answers4