Bug 126300 - 'su':inconsistent setting of XAUTHORITY env variable
'su':inconsistent setting of XAUTHORITY env variable
Status: CLOSED DUPLICATE of bug 87598
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-18 14:24 EDT by Tom London
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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):
coreutils-5.2.1-15

How reproducible:
Always

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 ***

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