Bug 126300 - 'su':inconsistent setting of XAUTHORITY env variable
Summary: 'su':inconsistent setting of XAUTHORITY env variable
Status: CLOSED DUPLICATE of bug 87598
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-18 18:24 UTC by Tom London
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2004-12-08 16:22:49 UTC

Attachments (Terms of Use)

Description Tom London 2004-06-18 18:24:39 UTC
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 20:25:08 UTC
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 22:58:40 UTC
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 16:22:49 UTC

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

Note You need to log in before you can comment on or make changes to this bug.