Re: X11Forwarding, ssh -X, and /bin/su

From: Per Hedeland (
Date: 07/09/04

Date: Thu, 8 Jul 2004 22:30:47 +0000 (UTC)

In article <> (bad_knee) writes:
>Darren Dunham <> wrote in message
>> > [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 ?


>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 ]
        if [ "${NFSHOME+set}" -a "$XAUTHORITY" -a \
                "$XAUTHORITY" != /tmp/.Xauthority.$USER ]
                cp $XAUTHORITY /tmp/.Xauthority.$USER
        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):


It caused some other weird problem that I've since forgotten, though...

--Per Hedeland