Re: X11Forwarding, ssh -X, and /bin/su
From: Per Hedeland (per_at_hedeland.org)
Date: 07/09/04
- Next message: Darren Dunham: "Re: X11Forwarding, ssh -X, and /bin/su"
- Previous message: Per Hedeland: "Re: SSH connections to two hosts with the same IP address"
- In reply to: bad_knee: "Re: X11Forwarding, ssh -X, and /bin/su"
- Next in thread: Bill Unruh: "Re: X11Forwarding, ssh -X, and /bin/su"
- Reply: Bill Unruh: "Re: X11Forwarding, ssh -X, and /bin/su"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 8 Jul 2004 22:30:47 +0000 (UTC)
In article <e817ca4d.0407081121.421847c5@posting.google.com>
bl8n8r@yahoo.com (bad_knee) writes:
>Darren Dunham <ddunham@redwood.taos.com> wrote in message
>
><snip>
>
>> > [foobar@server]$ su
>> > Password:
>> > # /usr/openwin/bin/xclock # this does not display
>> > X connection to server:11.0 broken (explicit kill or server shutdown).
>>
>> Hmm. Looks like display is set, and I don't see a permission error that
>> would point to a bad authority. Can you read the proper authority file
>> (often ~/.Xauthority)?
>
>
>After kludging around a bit, yeah, it looks like I have to export
>the DISPLAY variable again after su'ing.
That shouldn't be needed.
> I thought this was the reason
>ssh used the X11Offset (:10.0)?
You thought what was the reason? Anyway the reason is to avoid conflicts
with real X servers running on the same host, which will be listening on
:0 and up.
>Anyway, I got it working doing and 'export DISPLAY=clientbox:0.0',
>but I'm not really tunneled using ssh then, am I ?
No.
>I ran strace (gnu version) on xclock to see what was causing it to hurl,
>and it *was* barfing on .Xauthority of the user that su'd to root (I'm
>on solaris 9/sparc bash) -- permission denied.
And this is the crux of the problem, which doesn't really have anything
to do with ssh - it will happen whenever you use authentication for
connecting to the X server and have the home directory NFS-mounted
(unless you leave root unmapped over NFS, which is generally considered
a Bad Idea).
>The user that su'd has the home directory mounted via NIS and root has
>*no* write access to those home directories except on the NIS server.
You mean NFS, not NIS. And this non-access is generally achieved by
mapping root to something like "nobody" for the NFS access.
>If xclock is trying to write to .Xauthority it will fail, making the
>ssh tunnel fail as well??
It doesn't try to write it, but root-mapped-to-nobody can't *read* it
either, since it is (and should be) mode 0600.
>The Other option is to use /.Xauthority by doing an su - (login shell)
>instead of only su. This however requires exporting the DISPLAY to
>clientbox:0.0 and getting cleartext over port 6000, correct?
This is basically irrelevant - 'su -' doesn't fix anything in this
regard. As seen above, the problem is that root can't read the user's
~/.Xauthority file - that is what needs to be fixed. There are probably
many ways to do that, 'chmod 644' on the ~/.Xauthority file is not a
good idea though. Here's a snippet from a script that I use whenever I
want to 'su':
if [ ! "$XAUTHORITY" -a -f $HOME/.Xauthority ]
then
XAUTHORITY=$HOME/.Xauthority
fi
if [ "${NFSHOME+set}" -a "$XAUTHORITY" -a \
"$XAUTHORITY" != /tmp/.Xauthority.$USER ]
then
cp $XAUTHORITY /tmp/.Xauthority.$USER
XAUTHORITY=/tmp/.Xauthority.$USER
fi
export XAUTHORITY
This gets run before the actual /bin/su (or whatever) is executed. I
have a special environment variable $NFSHOME set whenever my home
directory is NFS-mounted, you probably don't, so you'll want to remove
the '"${NFSHOME+set}" -a' part from the second 'if'.
What it does, in short, is to copy the ~/.Xauthority file to a
root-readable place (/tmp) and set the environment $XAUTHORITY variable
to point there - all X clients will obey that setting rather than
looking at the (default) ~/.Xauthority.
Btw, some Linux systems (perhaps others too) have PAM modules that do
something like this "under the cover" when you 'su' - e.g. pam_xauth on
RedHat. After su'ing on RH7.2, I get this (not done by my script):
# echo $XAUTHORITY
/root/.xauthOKMNOu
It caused some other weird problem that I've since forgotten, though...
--Per Hedeland
per@hedeland.org
- Next message: Darren Dunham: "Re: X11Forwarding, ssh -X, and /bin/su"
- Previous message: Per Hedeland: "Re: SSH connections to two hosts with the same IP address"
- In reply to: bad_knee: "Re: X11Forwarding, ssh -X, and /bin/su"
- Next in thread: Bill Unruh: "Re: X11Forwarding, ssh -X, and /bin/su"
- Reply: Bill Unruh: "Re: X11Forwarding, ssh -X, and /bin/su"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
