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
