Re: X11Forwarding, ssh -X, and /bin/su
From: Bill Unruh (unruh_at_string.physics.ubc.ca)
Date: 07/09/04
- Next message: Per Hedeland: "Re: X11Forwarding, ssh -X, and /bin/su"
- Previous message: Darren Dunham: "Re: X11Forwarding, ssh -X, and /bin/su"
- In reply to: Per Hedeland: "Re: X11Forwarding, ssh -X, and /bin/su"
- Next in thread: Per Hedeland: "Re: X11Forwarding, ssh -X, and /bin/su"
- Reply: Per Hedeland: "Re: X11Forwarding, ssh -X, and /bin/su"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 8 Jul 2004 23:16:39 GMT
per@hedeland.org (Per Hedeland) writes:
]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...
Ah. Yes, it does. I have had situations where when I then tried to su to a
user it tried to read that file, and of course timed out after 40 sec .
- Next message: Per Hedeland: "Re: X11Forwarding, ssh -X, and /bin/su"
- Previous message: Darren Dunham: "Re: X11Forwarding, ssh -X, and /bin/su"
- In reply to: Per Hedeland: "Re: X11Forwarding, ssh -X, and /bin/su"
- Next in thread: Per Hedeland: "Re: X11Forwarding, ssh -X, and /bin/su"
- Reply: Per Hedeland: "Re: X11Forwarding, ssh -X, and /bin/su"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
