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

Re: Simple little basic config questions

%% brownh@hartford-hwp.com (Haines Brown) writes:

  hb> Johannes,
  hb> Took your advice, and that seems to have worked.

  hb>   $ xhost +local
  hb>   non-network local connection being added to access control list
  hb>   $ su
  hb>   Password:
  hb>   #

Well this doesn't prove anything: you have to run an X application as
root before you can know whether it worked or not.

This is still a bad idea, though, because anyone who can log into your
box (via telnet or whatever) can access your X server.  And anyone who
can access your X server can see every key you type, everything that
appears on your screen, etc. etc.

  hb> So I gave root access to the X server. Still don't understand why
  hb> I had to do this rather than it being the default setup with an
  hb> installation.

I'll try this...

It's not the default because, as above, it's a very insecure and silly
thing to do.  If you were able to start X applications from the command
line after running "su" on a Red Hat box, like this:

  $ su

  # xclock

then Red Hat must have opened up access to the X server, which is very,
very bad.  I'm _SURE_ they've fixed this by now, if they ever did it at

You should be reading Colin's posts: he's got the right answers.  Here
are some notes which might help you:

  * Whomever starts the X server (that is, runs startx from the console
    or logs in via XDM or GDM or whatever), has access to use the X

    If you log in as root through XDM or running startx, then root has
    access to the X server.  If you log in as yourself, then you have
    access to the X server.

  * Any other user, even root, even if you get to be that user by
    running "su", does _NOT_ have access to use the X server (by

  * Access is (typically) controlled by means of a special cookie,
    called the XAUTH cookie.  By default the user who starts the X
    server has that cookie, and no one else has it.  Whomever has that
    cookie, has access to the X server.

  * So, if you want root to have access to the X server via "su" after
    you started it yourself, you have to give root that cookie.  That
    can be done a number of ways, as previously described, but if you
    don't do this in some way then root can't access the X server.

  * Disabling access control via "xhost +" or "xhost +local" is a VERY
    BAD idea!  People with access to the X server are really very
    serious security risks.  If you must do it occasionally, be sure to
    undo it again quickly.  Much better is installing tools so you have
    a reliable, secure method to invoke X apps which doesn't require
    disabling your security.

    In addition to the already-mentioned sux there is gksu which pops up
    a graphical box to enter the password then starts an X app: this is
    good for adding to menus and stuff.  And, I have an "xsudo" script I
    wrote a few months ago which wraps sudo the same way sux wraps su
    (mine is lots shorter though so I'll have to look at sux and see
    what he's doing that I'm not :)).

You may feel that it's annoying to have to go to this extra trouble to
use X apps after running "su", especially if for some reason you didn't
have to before.  But, it's a very serious security issue, so you should
think of it as annoying in the same way having to type your password to
log in is annoying.

I hope this helps clarify things...

 Paul D. Smith <psmith@nortelnetworks.com>   HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
   These are my opinions---Nortel Networks takes no responsibility for them.

Reply to: