Bug 126300

Summary: 'su':inconsistent setting of XAUTHORITY env variable
Product: [Fedora] Fedora Reporter: Tom London <selinux>
Component: coreutilsAssignee: Tim Waugh <twaugh>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dwalsh, nalin
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-08 11:22:49 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Tom London 2004-06-18 14:24:39 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
Running coreutils-5.2.1-15 (and pam-0.77-44):

'su -l' usually sets XAUTHORITY to '/root/.xauthABCD
(ABCD unique stuff), except if you are running 'xauth' in
another window. Then it sets XAUTHORITY to "/home/user/.Xauthority".

On a 'stock FC2' machine running coreutils-5.2.1-7 (and pam-0.77-40),
su always sets XAUTHORITY to "/home/user/.Xauthority".

Setting XAUTHORITY to '/root/....' causes most window apps
(like up2date, seaudit, ...) to fail.

[Is this a reappearence of :
     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87598   ?]

Both machines are running xorg-x11-xauth-6.7.0-2, and both machines
are running SELinux enabled.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. 'su -l' from terminal window. 'echo $XAUTHORITY; exit'
2. run 'xauth' in another user window.  Leave running.
3. 'su -l' from terminal window. 'echo $XAUTHORITY; exit'

Additional info:
Comment 1 Nalin Dahyabhai 2004-06-18 16:25:08 EDT
I think the SELinux policy is causing a failure in pam_xauth
(specifically, a "permission denied" error attempting to read the
user's .xauth/export file to check that the invoking user wishes to
allow forwarding cookies to the target user -- any failure other than
"no such file" is treated as an error).  If anything pam_xauth
attempts to do fails in this way, it steps aside and does nothing,
leaving XAUTHORITY unmodified, holding a bad value.
Comment 2 Tom London 2004-06-18 18:58:40 EDT
Looks like xauth creates 2 'lock' files: /home/USER/.Xauthority-c and
/home/USER/.Xauthority-l.  They are mode 600, owned by USER, with
SELinux label user_u:object_r:user_home_xauth_t.

I don't see any AVC messages indicating SELinux denial (although 
I am running a broken sysklogd). Is it possible
that pam_xauth sees the lock files and 'silently' fails, leaving
XAUTHORITY unmodified?  'su' is not waiting for access to the lock.

Assuming that is the case, could this lead to some sort of DOS
(or other) situation, where a malicious app of some sort creates 
files that mimic these lock-files, thereby fooling pam_xauth? 
I would think this would be a more realistic scenario
if the system was not running SELinux/enforcing.....

Is there some 'safe' fall-back value for XAUTHORITY that pam_xauth
could use in this case?
Comment 3 Tim Waugh 2004-12-08 11:22:49 EST

*** This bug has been marked as a duplicate of 87598 ***