xhost +localhost

[Gert Cuykens]

On Fri, 4 Feb 2005 22:47:04 -0800, Loren M. Lang <lorenl at alzatex.com> wrote:
> 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.
> 

Thx this clears alot of questions :)
One more question doh, about the x cookie.

How long does it take to calculate the x cookie string yourself of a
user you want to hack :)