Warning: Function ereg() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 4

Warning: Function split() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 19

Warning: Function ereg() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 4

Warning: Function split() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 19

Warning: Function ereg() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 4

Warning: Function split() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 19

Warning: Function ereg() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 4

Warning: Function split() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 19

Warning: Function ereg() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 4

Warning: Function split() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 19

Warning: Function ereg() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 4

Warning: Function split() is deprecated in ..../includes/class_postbit.php(345) : eval()'d code on line 19
gdm works, kdm don't
Results 1 to 6 of 6

Thread: gdm works, kdm don't

  1. #1
    Mentor
    Join Date
    Jun 2001
    Posts
    1,672

    gdm works, kdm don't

    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:

    Code:
    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?



  2. #2

    Re: gdm works, kdm don't

    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 -

  3. #3
    Mentor
    Join Date
    Jun 2001
    Posts
    1,672

    Re: gdm works, kdm don't

    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.

  4. #4
    Guest

    Re: gdm works, kdm don't

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

  5. #5
    Mentor
    Join Date
    Jun 2001
    Posts
    1,672

    Re: gdm works, kdm don't


    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.


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

  6. #6

    Re: gdm works, kdm don't

    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.

Similar Threads

  1. Synaptic works once then MIA
    By DamselNDistress in forum Linux - Software, Applications & Programming
    Replies: 7
    Last Post: 07-10-2005, 09:59 PM
  2. IE can't display but DNS works ...
    By Compunuts in forum Windows - General Topics
    Replies: 9
    Last Post: 11-05-2004, 04:35 AM
  3. Anyone using a trackball that works?
    By dragon5 in forum Linux - Hardware, Networking & Security
    Replies: 5
    Last Post: 08-17-2003, 02:39 AM
  4. UDP works, TCP doesn't
    By metrik in forum Linux - Hardware, Networking & Security
    Replies: 2
    Last Post: 10-24-2002, 09:59 AM
  5. Does anyone know how activeX works?
    By tolstoy in forum Linux - Software, Applications & Programming
    Replies: 4
    Last Post: 05-16-2002, 01:57 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •