På 1999-Aug-27 klokka 17:02:32 -0700 skrivet David Aue:
: Okay I'm kinda following you here. Unfortunately the man page doesn't
: really describe the scheme but I can see that there are some add and
: generate commands. The problem more specifically turns out to be that
: if I login into my personal account and then su to another account I
: can no longer run X programs. From poking around with xauth it looks
: like loging in with xdm creates some per session cookies for the logged
: in user and then su ing to another account changes over to the other
: accounts .Xauthority which has no cookies for the current session. So
: it would seem I need some kind of permenent cookie in the .Xauthority
: of the account I am su ing to.
If you su to a user which has read access to your ~/.Xauthority, you
can do the following:
XAUTHORITY="${HOME}/.Xauthority"
export XAUTHORITY
(or the equivalent csh command: setenv XAUTHORITY"${HOME}/.Xauthority").
Setting the XAUTHORITY envariable tells X to look for authority
information there rather than in the default location of ~/.Xauthority.
If you su to a user which does not have read access to your
~/.Xauthority, you may need to manually add a cookie to that user's
~/.Xauthority using xauth. For example:
xauth list
[select the relevant line or lines for your display using the mouse]
su <user>
xauth add [middle-click to paste the line you selected earlier]
Alternatively, if you have ssh available, you can use its X display
forwarding feature (usually on by default) to get around the Xauthority
problem:
ssh -l <user> localhost
With display forwarding on, ssh will set up a pseudo-display and handle
setting a cookie in <user>'s ~/.Xauthority file automagically.
See the Xsecurity man page (it's in section one in my XFree86
distribution) for more info about Xauthority files.
--jim
%%%%%%%%%%%%%%% jim knoble %%%%%%%% jmknoble@??? %%%%%%%%%%%%%%%%%
