up2date/seaudit/... not working (EXPLAINED)

[Nalin Dahyabhai]

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