xhost +localhost

[Loren M. Lang]

On Fri, Feb 04, 2005 at 12:21:34AM +0100, Gert Cuykens wrote:
> On Thu, 3 Feb 2005 14:58:35 -0800, Loren M. Lang <lorenl at alzatex.com> wrote:
> > This enable all programs to have access that are using unix domain
> > sockets to not need the MIT-MAGIC-COOKIE stored in the .Xauthority file
> > in the users home directory so any user can open a program on that
> > display.  xhost +localhost adds all programs from localhost using tcp
> > connections instead.  DISPLAY=:0 causes a program to use fast unix
> > domain sockets where DISPLAY=localhost:0 causes a program to use slow
> > tcp sockets instead.  tcp sockets are really only needed for remote
> > connections and xhost +localhost won't allow any local programs to
> > access X unless they use tcp, not unix.  See my first response for more
> > information.
> 
> ok time out :)
> 1)does xhost set the DISPLAY variable ?

No, in fact, xhost needs the DISPLAY variable already set so that it
knows which display to try and connect to to change access control.
xhost needs some way to authenticate itself to the X server so X can
trust that it's a legit user trying to change the access control.  If
you open up X to all local users by using something like xhost
+localhost or xhost local: then any local user could take over your
display and use xhost to disable your access to it.

> 2)does xhost local: also uses the tcp thingie or use it the x socket thingie ?

local: allows anyone to access the X server through unix domain sockets.
+localhost allows all local programs to access X though tcp sockets.
Normally tcp sockets are only used for remote connections since they are
slower than unix sockets, but unix sockets only work on the same
machine.

> 3)what must i put in the .Xauthority file to make the screensaver work
> with having to use xhost ?

When X first logs in to a user, it creates the .Xauthority file in that
users home directory and fills it with a random string called a
MIT-MAGIC-COOKIE.  Any X client, by default, reads that file to see what
the cookie is then sends it to the X server to authenticate itself.
Anyone who can read that file can access the display so that file is
normally only readable by the user who logged in, though root can always
read it because root is god.  When you run an X program as a different
user, it will look in that users home directory for the .Xauthority
file and so won't be able to find the right cookie unless you used the
xauth command to give that user the cookie ahead of time.  By setting
the XAUTHORITY environment variable to some other file, it will check that
file for the magic cookie instead of the current users home directory.
This is useful when running a command as root that you want to access a
normal users X server.  This is a much more secure way to allow access
to X than using xhost since you know what users are able to access X,
not just which computers, which may have multiple users on them.

In summary, don't touch xhost, just use:

XAUTHORITY=/home/user/.Xauthority xscreensaver

or you can use xauth to extract the magic cookie and then import it into
the correct users .Xauthority file.  As the user of the X server:

xauth extract my-cookie-file $DISPLAY

Saves the magic cookie to a file called my-cookie-file for the current
display.  Then as the user who want to access the X display:

xauth merge my-cookie-file

Adds the cookie stored in my-cookie file to the current users
.Xauthority file.  Now user B can open an X application on A's X server.

Oh, and don't run xscreensaver as root EVER!  Instead, if you're really
paranoid about security, make a user who can access any of your files
whose sole purpose is to run xscreensaver then use that user to run it.
This is still not that much more secure since any user that can access
an X server can essentially take it over and control your mouse and
keyboard doing what ever they want, like openning an xterm on your
display and running the passwd command to change your passwd.  Now they
just gained access to all your files as well.


-- 
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.

Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD  835A FAF3 7A46 E4A3 280C