Usage
copy & paste
Symptom
tong@sunny:~$ xterm
Xlib: connection to "sunny:11.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
xterm Xt error: Can't open display: sunny:11.0
tong@sunny:~$ DISPLAY='chaos:0.0'
tong@sunny:~$ xterm
Xlib: connection to "chaos:0.0" refused by server
Xlib: Client is not authorized to connect to Server
xterm Xt error: Can't open display: chaos:0.0
Resolution
tong@chaos:~$ xauth list
chaos:0 MIT-MAGIC-COOKIE-1 376f307045725251544d6b734f477268
tong@sunny:~$ xauth add \
chaos:0 MIT-MAGIC-COOKIE-1 376f307045725251544d6b734f477268
— NP!
Symptom
change back to security way:
tong@sunny:~$ DISPLAY='sunny:11.0'
tong@sunny:~$ xterm
Xlib: connection to "sunny:11.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
xterm Xt error: Can't open display: sunny:11.0
tong@sunny:~$ xauth list
sunny:11 MIT-MAGIC-COOKIE-1 82b1b590b7d7170aee11632d59b09498
|
tmp solution |
server
xauth extract - $DISPLAY > ~/s/tmp/xc.$HOST_N_S.bin
client
ls ~/s/tmp/xc.*.bin
xauth merge - < `!!`
client
A good document on Xauth is available at
ftp://ph-meter.beckman.uiuc.edu/security/xsecurity.txt
Vivek Khera (khera@cs.duke.edu) discusses how to start the X server in a
secure mode. Note that it's specific to Sun.
<URL: http://ce-toolkit.crd.ge.com/tkxauth/> is the URL for information on
using/debugging Tk vs X windows authorization problems.
http://www.xs4all.nl/~zweije/xauth-6.html
The best
http://ciac.llnl.gov/ciac/documents/ciac2316.html#2.0
Usage
gksu [-u <user>] [options] <command>
gksudo [-u <user>] [options] <command>
Info
gksu - GTK+ frontend for su and sudo
Description
gksu is a frontend to su and gksudo is a frontend to sudo. Their primary
purpose is to run graphical commands that need root without the need to run
an X terminal emulator and using su directly.
Detail Help
--preserve-env, -k
Preserve the current environments, does not set $HOME
nor $PATH, for example.
--login, -l
Make this a login shell. Beware this may cause
problems with the Xauthority magic. Run xhost
to allow the target user to open windows on your
display!
documented on: 2007-12-09
The X server can control a user's access to an X server through the use
of a magic cookie. This is essentially a machine-readable, randomly
generated access code. Each X client must provide the same magic cookie
value to the server before being allowed access. This value is stored in
the file .Xauthority. It can be either created by the X Display
Manager, or by the user, at the beginning of each session.
The xauth program is used for editing and displaying the user's magic cookie
authorization information. Once the magic cookie is displayed in a
human-readable form, it can be sent to a remote host. On that remote host,
xauth is used again to merge the magic cookie into the user's .Xauthority
file. Assuming a .rhosts file is set up for the user, pushing the
authorization information to a remote host (let's say ahost.foo.org) can be
done with one command:
xauth extract - $DISPLAY | rsh ahost.foo.org xauth merge -
The first command prints the magic cookie for the current host
($DISPLAY) to the standard output (the dash). This information is then
piped to the remote shell command, which runs the xauth program on the
machine ahost.foo.org. The magic cookie is then read from the standard
input (again, the dash), and merged into the .Xauthority file. The
result is that the user who executed this command can now run X clients
on ahost.foo.org, and have them displayed on the X Server. It is
important to have the permissions set correctly for the .Xauthority
file. It should be readable/writable by the owner only (that is, set to
"-rw-------"). Furthermore, beware of NFS exporting a home directory,
even read-only! It may be mounted, allowing the .Xauthority file to be
read.
Note the key improvement here. The user who ran this command is now the
only user on ahost.foo.org who can connect an X client to their X
server. All other users on ahost.foo.org are still blocked out of this X
session.
testing history
xauth extract - $DISPLAY | ssh -v sunny /usr/X11R6/bin/xauth merge -
-
specify xauth alone ssh will complain that xauth not found.
-
remote program invoked but not work
-
"xauth list" on clint side show nothing changed.
xauth extract - $DISPLAY | ssh -v sunny cat -
— yes, show exactly as locally!?
— from chaos and iitrc produce the same result
Newsgroups: comp.os.linux.misc,comp.os.linux.x
Date: Thu, 16 Jan 2003 16:30:32 GMT
> First I login as one user at int the XDM login window to start the X server,
> everything is OK.
> Then, in an Xterm, I use the ``su'' command to change to another user( another
> common user, or even root ). But I can not run any X client now. The
> error message is:
>
> Xlib: connection to ":0.0" refused by server
> Xlib: Client is not authorized to connect to Server
> Error: Can't open display: :0.0
The original user "owns" the Xserver, and any other user cannot connect to
it without authorization. There are several 'workarounds'. One is to use
'xhost' to disable access control (for the world—dangerous if you're on
a network which contains strangers; for 'localhost'—probably okay if
no others can log in to your local machine; using 'xauth' to obtain
a magic cookie from the owner of the Xserver, and placing it in the
'cookie jar' of the other user—see "Remote-X-Apps mini-HOWTO".)
Dave Brown
Can't connect to X server after su !!!
> The original user "owns" the Xserver, and any other user cannot connect to
> it without authorization. There are several 'workarounds'. One is to use
Or, two other options:
-
See if your distro has the command "sux" which is su+x.
-
Put these lines in root's .bashrc:
if [ "$USER" != "root" ] ; then
export XAUTHORITY=`eval echo ~$USER/.Xauthority`
fi
That should fix it. I copied this from someone else, so I'm not a guru.
Soft Edges
Can't connect to X server after su !!!
Thank you. Please report to the duty torturer. A little something off
the ears I think.
If you must do this, at least do "xhost +localhost" to avoid creating
a security hole larger than you could get an elephant through.
Even better, enable X forwarding in ssh and do "ssh -l root localhost".
John
