Bug 126300
| Summary: | 'su':inconsistent setting of XAUTHORITY env variable | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom London <selinux> |
| Component: | coreutils | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dwalsh, nalin |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-12-08 16:22:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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? |
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: