%% [EMAIL PROTECTED] (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
Password:
# 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
all.
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
server.
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
default).
* 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 <[EMAIL PROTECTED]> 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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
