[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Xlib: Invalid MIT-MAGIC-COOKIE-1 key

> * Eric Jacoboni <jaco@DIAL.OLEANE.COM>
> |
> | I've some problems with some programs under X : when i try to run
> | xosview, for exemple, i get the following message :
> | 
> | =-=-=-=-=-=-=-=-=
> | titine:~# Xlib: connection to ":0.0" refused by server
> | Xlib: Invalid MIT-MAGIC-COOKIE-1 key
> | Can't open display named 
> | =-=-=-=-=-=-=-=-=
> | 
> | Since i'm new to the Debian system, i'd like to know where to
> | configure such an information.
> Since your prompt shows a "#" I assume you try this as root. From the
> error I also assume that you have logged in as another user.
> The reason you get this error is because user B is not allowed to
> open windows on a display controlled by user A. If user A wants to
> allow this, he can type 'xhost +localhost' to allow everyone on
> localhost to open windows.
> 'man xhost'
> -- 
> .elOle.

Rather than open up the whole X Server so that any local user can
there are progressively more complex techniques to permit a specific
user to connect.

+	# cp ~user/.Xauthority ~

This will copy the Xauthority file from the named user to roots' home
directory, overwriting any previous permissions given to root.

This will need to be done each time that a new xdm/scologin/dtlogin
session is started.  Within a single session you can 'su' and exit as
many times as you want.

+	$ xauth extract /tmp/foo titine:0
	# xauth merge /tmp/foo

This pair is also done once per session.  As the ordinary user that
started the session, write the data to something that the superuser
(only) can access.  Email is another good mechanism to send the keys to
"root" (or another identified user).  The user granted access can then
use the extracted data to add the Server key to their keys file.

The principle is that Xauthority uses a key to secure access to the X
Server.  It is more secure than using "xhost +" or even "xhost
+localhost" or other variants of xhost command lines.  There is still
some security susceptibility as the standard xauth mechanisms all
transmit the key in plain form on the network, which means that someone
with a snooper can see the key and reproduce it for themselves.  This
does require some degree of sophistication on the part of the would be
system penetrant, and also means that they must have penetrated some
other system in your network to be able to perform the network data
scan.  For most systems inside a firewall xauth will provide more
practical security than xhost; if being used on the Internet, you
probably don't want to trust xauth or xhost alone.  Some tool such as
ssh can be helpful in authenticating session connections.

Cheers, JeremyC.
Jeremy Chatfield, Xi Graphics  mailto:jdc@xig.com  tel:+44(0)1234.710030 
 Commercial X Products: Servers, CDE, contracts and custom development
    http://www.xig.com ftp://ftp.xig.com/ mailto:majordomo@xig.com
     tel:+1.303.298.7478  fax:+1.303.298.1406  mailto:info@xig.com

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply to: