I have a script that is running as root and that eventually tries to start an X program as “user” (assuming that “user” is currently running X).
The following used to work in OpenSUSE <= 11.0, but doesn’t anymore in OpenSUSE 11.3:
sudo -u user DISPLAY=:0.0 xterm
Now it gives the following error message:
No protocol specified
xterm Xt error: Can't open display: :0.0
Can someone explain to me
The X program assumes that it has to open the window on (logical) display :0.0 (which is the first screen on the first display on the local system). After all there can be many displays on your as well as on other systems on the network.
That asks for two things:
that that is realy the display wanted, in other words that the user user is loged in on display 0 of the local system (thus not using one of the other logical displays that you can reach on your system using Ctrl-Alt-F#, where F7 is normaly display 0).
that the user allowes this. Try this again after the loged in user did
xhosts +
on a terminal within his session.
Now this will open the display to everyone from everywhere. To fine tune read
man xhost
It doesn’t work because the user cannot read root’s $HOME/.Xauthority file, and unless the display was started by that user, and the X-display authentication info is not in that user’s .Xauthority.
I occasionally do what you want, except that I use “ssh user@localhost” rather than “su”. I do two “ssh” calls. The first passes the “.Xauthority” information. Then the second runs xterm in the background with stdin, stdout, stderr all redirected to root so that the xterm will be detached from the original terminal and the sshd process can exit after starting the xterm.
Thanks for the replies, but I don’t think you guys are right.
@Henk:
@nrickert:
It is supposed to read ~user/.Xauthority though… and again, I’m assuming that “user” is currently running X…
Either way, I found that this actually still works on an 11.3 system where I installed plain xdm along with xfce. The system where it did not work was using gdm/gnome. Also the 11.0 system where it worked was using kdm/kde3. So maybe this is an issue with gnome…
I will investigate this some more…
You misunderstand. It has not much to do which the fact which user it is. It is has to do with the fact that the Display (that is the working X session) is protected from others (not other users, but other sessions) to create windows (or do other things with that X session). This protection does function regardless which is the user running that other section. This fact most often amazes prople who think that root can do everything, but it is also true when the user is the user. Also “same host” is no argument here. X is a network service, there is no difference between same or other hosts.
I post this to help you undersstand the xhost mechanism and it’s alternatives (like .Xauthority as @nrickert points to).
I am not sure if it realy is what you are after and if this is more restricted then before. But the general idea is as described.
I had that working with an 11.0 system and gnome.
It continued to work for me with 11.3 and KDE, until I tried it on a 64 bit system. To get it to work on the 64 bit system, I found that I had to also set XAUTHLOCALHOSTNAME in the environment. The script I used for 11.3 continues to work with 11.4 KDE.
To clarify, I occasionally use this as a non-root user to start an xterm as root, or to start an xterm as a different user. When starting an xterm as root, I make sure that XAUTHORITY is set in the root environment before starting the xterm (root can read my .Xauthority). When starting an xterm as a different non-root user, I first make sure that I export the ‘.Xauthority’ magic cookie for the session, and import that into the target user’s ‘.Xauthority’ file (bascially “xauth extract - $DISPLAY” is piped to “xauth merge -” over an SSH channel (ssh to targetuser@localhost using public key authentication).
There is actually a big difference. When you run clients locally, they communitcate with the X server using local IPC (unix sockets, shared memory etc). No network involved.
Also we have already established that it can work, so clearly it is not a fundamental issue with X… I’m still trying to find out what the difference is that makes it not work on that one installation.
That s of course true, but it is under the hood and of no concern in understanding that an X server is a server with network capabilities. It does not matter if the underlying network part is implemented with the TCP/IP stack or with Unix sockets (or with a courier running to and fro with the messages).
Finally found the problem: GDM does not generate $HOME/.Xauthority anymore!
well i have the same problem and modify .bashrc in /home adding, export display=:0.0, in the last line