gdm works, kdm don't

[cloverm]

Got this weird situation:

If I use gdm as my display manager everything works fine. But if I use kdm (which I would prefer) I get this error message when trying to run certain programs:

Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
xhost: unable to open display ":0.0"

If I log in as root from kdm, I don't get this error, so it has to be a problem with permissions. But how do I set up kdm to get rid of this stupid error?

[civ1492]

hmm try xhost +<yourusername> or xhost + , but xhost + allows everyone to acces your X server so its not a very secure idea .. you can undo it with xhost -

[cloverm]

hmm try xhost +<yourusername> or xhost + , but xhost + allows everyone to acces your X server so its not a very secure idea .. you can undo it with xhost -

Thanks, but that didn't work. If I log in with kdm as a regular user then su to become root and issue xhost +, I get the same exact error message (as root!). There must be a setting in kdm, I just don't know what that might be.

check to see if /var/log/kdm.log gives u more info

[cloverm]

check to see if /var/log/kdm.log gives u more info

I checked the log the log. I don't see anything unusal, except for the last 2 lines which is the same error I'm getting.

AUDIT: Fri Jan 25 22:11:24 2002: 253 X: client 14 rejected from local host
 Auth name: XDM-AUTHORIZATION-1 ID: -1

[mdwatts]

I did a Google search for 'Xlib: Client is not authorized to connect to Server' and the following is from one of the search results.

I have two Linux desktop machines. My old one is a 486-66 running Red Hat 5.2. I can use su to become root or another user to my heart's content. My new system runs Mandrake 6.1 and has an AMD K-6, 450 MHz processor. Everything is a lot faster, but I can't su. Actually I can, but then I get an error message if I try to run any X11 application under my new temporary user identity. The error message says this:

Xlib: Connection to ":0.0" refused by

server Xlib: Client is not authorized to connect to server

Then come application-specific error messages, like this:

kmail: Cannot connect to server: 0

Please help! What's going on here? What do I need to do?

Serving Screens in Syracuse

Dear Serving,

I can easily tell you what's got your work at bay. The older system had a weaker security plan that allowed anyone on the system to use its X display. If you'd like to go back to those old days, darling, it's a snap. Just slip this into the startx script, and anyone with access to the system will be able to run the X applications:

xhost +localhost

Once upon a time, the old days allowed easy entrance into anyone's X desktop. If you ran the command xhost + you could let the whole Internet use your screen. Eeek! In fact, that's what xhost is for...think rhost. It says that this machine is okay; don't even bother asking it for an entrance pass.

Now I really must congratulate you, hon, on the wherewithal to create separate user IDs for all the hats you wear. Lots of system administrators talk about doing this but aren't actually, well, doing it. You get a cookie, dear. In fact, every time you start up X you get a cookie...an MIT-MAGIC-COOKIE-1 that is. In fact, it's entirely possible you'll receive a somewhat more secure and tasty XDM-AUTHORIZATION-1, but that depends on your distribution. How can you tell if you have an MIT or XDM cookie? Ask it!

The pantry your cookies are kept in is your ~/.Xauthority file. So, run strings to see the parts of it that are readable:

strings .Xauthority

The results you'll get will look something like this:

MIT-MAGIC-COOKIE-1 mybox MIT-MAGIC-COOKIE-1 MIT-MAGIC-COOKIE-1

This bit of sugary snack (just a small check, are you the one that opened the X session) is what's preventing you from effectively using X. But, it's a ginger snap -- control your own cookie jar with xauth. Using these cookies is the only way to be sure you're safe on a multi-user system.

If you're becoming root, then fixing it is simply no problem. Set an environment variable named XAUTHORITY to point at the .Xauthority file from the user you started up X as. Since it already has the cookie in it, it will be perfectly correct. Next, copy the files, and if you're not becoming root, that'd be the best way to share them. You can generate your own, more secure cookie and use that instead:

xauth add :0 XDM-AUTHORIZATION-1 [put a whole lot of hex characters here... an even number of them]

...and then give that secure cookie to your other accounts:

xauth extract - :0 | ssh -l otherhat@localhost xauth merge -

If that doesn't help, then perhaps trying the search yourself may provide the correct solution.