Red Hat Bugzilla – Bug 126300
'su':inconsistent setting of XAUTHORITY env variable
Last modified: 2007-11-30 17:10:44 EST
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 :
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):
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'
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.
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?
*** This bug has been marked as a duplicate of 87598 ***