Date: Fri, 4 Feb 2005 22:47:04 -0800 From: "Loren M. Lang" <lorenl@alzatex.com> To: Gert Cuykens <gert.cuykens@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: xhost +localhost Message-ID: <20050205064704.GH8619@alzatex.com> In-Reply-To: <ef60af0905020315216fc3765a@mail.gmail.com> References: <ef60af09050202095829be3b6f@mail.gmail.com> <20050202210526.GC77499@keyslapper.net> <42014E0A.5070003@mac.com> <20050203225835.GX8619@alzatex.com> <ef60af0905020315216fc3765a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050205064704.GH8619>