On Mon, Jan 24, 2000 at 02:59:49PM +0100, Alexander N. Benner wrote: > Ship's Log, Lt. Ruud de Rooij, Stardate 200100.1618: > > Actually, it's probably cleaner to simply do > > > > XAUTHORITY=/home/someone/.Xauthority > > or just use sudo which let's these env. untouched. > (which I would suggest anyway as a clearer and more flexibel way to share > different rights) I don't suppose anyone has read my FAQ on the subject? From /usr/share/doc/xfree86-common/FAQ.gz: *) How do I run an X client as root when the X session is run by a user? If a normal user is running an X session (from startx or xdm), and that user, for instance, uses the su command from within an xterm to become root and then runs a program that tries do so something with the X server, the following error messages (or something similar) are usually seen: Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server This happens because of an X security mechanism, which uses "magic cookies" stored in a file in the user's home directory (readable only by the user) called .Xauthority. If the environment variable XAUTHORITY is not set (see below), X clients attempt to authenticate themselves by using the .Xauthority file found in the directory specified by the HOME environment variable. Of course, if user "branden" is running the X session, and he then uses su to become root, $HOME will be "/root" instead of "/home/branden", and the correct .Xauthority file will not be found (even if there is an .Xauthority file in /root, it will not contain the correct magic cookies unless the root user has deliberately made it that way). There are therefore a number of ways to solve this problem. If only one user ever becomes root, and if root never starts an X session, there is a one-step, permanent solution (provided you don't rearrange your filesystem). Become root, then: cd ln -s /home/branden/.Xauthority .Xauthority Of course, you will want to replace "branden" in the above example with the name of whatever user has access to the root account. Alternatively, and more appropriate for more complex situations than the one described above, you may simply issue commands while root that will tell the X clients where to look for the .Xauthority file. If you set the XAUTHORITY environment variable to the path to the appropriate user .Xauthority file. If the su command is used, all of the environment of the invoking user is inherited except for $PATH; therefore, each user who has access to the root account could set the XAUTHORITY variable in their shell startup files, and this variable will be passed to the root shell. Other alternatives include modifying the root shell startup files to sense the invoking user and setting XAUTHORITY, making command aliases that set that variable for the invocation of specific commands, or configuring the super or sudo programs with appropriate rules. The most straightforward method (but not the one that requires the least typing), is simply to set XAUTHORITY with each command you issue as root that needs to access the X server. For Bourne-type shells (sh, bash, ksh, zsh): XAUTHORITY=/home/branden/.Xauthority xeyes For C-shell-type shells (csh, tcsh): ( setenv XAUTHORITY /home/branden/.Xauthority; xeyes ) Finally, you should NEVER, EVER use the xhost command to manage X server access control unless you know exactly what you are doing (even then, there's hardly ever a good reason short of seeing just how many ways the security of your system can be compromised). Use the xauth command instead; the EXAMPLES section of its manual page is instructive for the most common tasks. -- G. Branden Robinson | If a man ate a pound of pasta and a Debian GNU/Linux | pound of antipasto, would they cancel branden@ecn.purdue.edu | out, leaving him still hungry? roger.ecn.purdue.edu/~branden/ | -- Scott Adams
Attachment:
pgpw_sVRCZCCr.pgp
Description: PGP signature