xauth changes XAUTHORITY in su (was Re: up2date/seaudit/... not working (EXPLAINED))
Nalin,
Stephen Smalley's fix (move line in /etc/pam.d/su) fixed much of the
problem,
but running 'xauth' in another window still changes the setting of
XAUTHORITY
in the root shell that su spawns....
So, without xauth running, XAUTHORITY gets set to /root/.xauthABCD;
with xauth running, XAUTHORITY is unmodified (i.e., its value is
/home/USER/.Xauthority).
tom
[I didn't report that prior to the fix, 'su' was taking 20 seconds to
complete after entering
the correct password. This delay is now gone.]
------------------------------------------------------------------------
* /From/: Nalin Dahyabhai <nalin redhat com>
* /To/: fedora-selinux-list redhat com
* /Subject/: Re: up2date/seaudit/... not working (EXPLAINED)
* /Date/: Fri, 18 Jun 2004 16:28:15 -0400
------------------------------------------------------------------------
On Fri, Jun 18, 2004 at 12:00:44PM -0700, Tom London wrote:
Running off of the development tree, I couldn't get graphical
apps (like
up2date, seaudit, ...) working when su'ed as root. All of this works
fine on a 'stock FC2' machine (running off
of the base and released-updates trees).
The problem seems to be that the latest packages cause 'su' to change
the settings of XAUTHORITY environment variable from
'XAUTHORITY=/home/USER/.Xauthority' to
'XAUTHORITY=/root/.xauthABCD' (ABCD the usual 'uniqueness' stuff).
If you manually reset XAUTHORITY back to '/home/USER/.Xauthority', the
apps work
again.
Here's a bit of added strangeness: if you start 'xauth' in another user
window and then
try 'su -l', XAUTHORITY is not changed in the root shell. No AVCs against
/root/.authABCD either....
[On the 'stock FC2' machine, XAUTHORITY is not modified by su.]
I've bugzilla'ed this
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126300)
against coreutils, but I'm not sure that is the right place (e.g.,
pam?). (All my systems
run with SELinux enabled, so I can only assume this is occurring on
SELinux-disabled
systems as well.)
Can someone explain why 'su' would be changing XAUTHORITY ?
The pam_xauth module reads the cookie for the current display for the
invoking user and creates a temporary cookie file containing just that
cookie for the target user.
While this isn't always necessary, if the invoking user's $XAUTHORITY is
in an NFS-mounted directory coming from a server which uses
root-squashing (and $XAUTHORITY is usually set to ~/.Xauthority, so it
happens), it becomes necessary because $XAUTHORITY would otherwise be
inaccessible.
If for some reason pam_xauth isn't able to do what it attempts to do, it
leaves the XAUTHORITY environment variable unchanged, so the behavior
you were seeing before was probably a bug of some kind.
I'm not sure how running another copy of 'xauth' would affect this,
really. xauth locks files when it opens them, but that should cause
'su' to just sit there until the copy of xauth which it started fails,
and you didn't mention any such delay.
Nalin