Blog dedicated to Oracle Applications (E-Business Suite) Technology; covers Apps Architecture, Administration and third party bolt-ons to Apps

Monday, March 24, 2008

Xlib: Invalid MIT-MAGIC-COOKIE-1 key

When I executed xhost + command on a Solaris box as root. I got the following error:

root@apps11i # DISPLAY=apps11i:1
root@apps11i # export DISPLAY
root@apps11i # xhost +
Xlib: connection to "apps11i:1.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
xhost: unable to open display "apps11i:1"

This error is the correct behavior because xhost + command can be executed by that user who has started the X session. Solaris is protecting a particular user's processes by disallowing other users to control it. In my case it was a vnc session started through a different user. Once I logged in as that user

root@apps11i # su - applmgr
applmgr@apps11i # xhost +
access control disabled, clients can connect from any host


Frits Hoogland said...

Are you aware that you have opened your X server validated as root for your entire network?

Doesn't seem like a good idea.

Better to use SSH X-tunneling, and re-use your X cookie(s) in the root session:

$ xauth list > /tmp/x.authentication.cookies
$ su -
# cat /tmp/x.authentication.cookies | while read COOKIE; do
xauth add $COOKIE

Vikram Das said...

Yes I am aware of that. I'll try what you have suggested. The other way is to xhost particular hosts only.

frits hoogland said...

small correction: only "su" works, not "su -"; "su -" resets the environment, which means also the DISPLAY variable is reset.

Another option is to allow root connections via ssh using localhost, which mean you could forward your tunneled X session using "ssh -X root@localhost". If root & X are really necessary this is an option, but also not a very secure one.

it may sound a bit paranoid, but it's best not te leave any paths open which could allow traffic to root or a root session directly.

this means that xhost + particular hosts is not secure.

If you are curious about X tunneling and a following X session (which means you can hop to any server using ssh and keeping X working), see:

mercury said...

Adding -ac to the startup command solved my problem. See this for more infomation

P.S. This is NOT a link to my blog

Anonymous said...

also using ssh -YX user@host will turn off xauth completely or ignore it in a pinch.

Anonymous said...


Thanks a lot...
We got the same error and We used X cookies in the root session.

It worked out :)