Bug 441831

Summary: "su -l" take ~20 seconds, /usr/bin/xauth "hanging"?
Product: [Fedora] Fedora Reporter: Tom London <selinux>
Component: xorg-x11-xauthAssignee: Søren Sandmann Pedersen <sandmann>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: jeff, kem, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-11 19:13:20 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:
Bug Depends On:    
Bug Blocks: 235706    

Description Tom London 2008-04-10 13:47:37 UTC 
Description of problem:
After the gdm change moving the auth tokens from /tmp to /var/run/gdm, running
"su -l" now takes much longer to complete successfully (about 15-20 seconds).

Running "ps agxw" during the apparent hang shows:

 4160 pts/0    S+     0:00 su -
 4164 pts/0    S+     0:00 /usr/bin/xauth -f
/var/run/gdm/auth-cookie-XXPMV48T-for-tbl nlist :0.0

[Not sure where to log this.  Sorry if this is not the right package....]

Version-Release number of selected component (if applicable):
xorg-x11-xauth-1.0.2-4.fc9.i386
gdm-2.21.10-0.2008.04.08.2.fc9.i386

How reproducible:
Every time

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Tom London 2008-04-10 17:32:47 UTC 
Running xauth manually generates a timeout:

[tbl@localhost ~]$ time xauth -f /var/run/gdm/auth-cookie-XXVOE28T-for-tbl nlist
:0.0
xauth:  timeout in locking authority file /var/run/gdm/auth-cookie-XXVOE28T-for-tbl

real	0m20.004s
user	0m0.001s
sys	0m0.001s
[tbl@localhost ~]$ 

Running as root, works fine:

[root@localhost ~]# time xauth -f /var/run/gdm/auth-cookie-XXVOE28T-for-tbl
nlist :0.0
0100 0015 6c6f63616c686f73742e6c6f63616c646f6d61696e 0001 30 0012
4d49542d4d414749432d434f4f4b49452d31 0010 d4bd245aa5f5c11796f5092a13888311

real	0m0.003s
user	0m0.000s
sys	0m0.002s
[root@localhost ~]#
Comment 2 Tom London 2008-04-10 17:58:00 UTC 
[tbl@localhost ~]$ ls -lZ /usr/bin/xauth
-rwxr-xr-x  root root system_u:object_r:xauth_exec_t   /usr/bin/xauth
[tbl@localhost ~]$ 

Is there a missing transition to xauth_t?
Comment 3 Jeffrey C. Ollie 2008-04-11 17:39:47 UTC 
I'm seeing this as well - it affects SSH connections in a similar manner.

xorg-x11-xauth-1.0.2-4.fc9.x86_64
gdm-2.21.10-0.2008.04.08.4.fc9.x86_64
Comment 4 Tom London 2008-04-11 18:07:08 UTC 
running 'strace xauth' produces:

<<<<<SNIP>>>>>
mprotect(0x3cd000, 8192, PROT_READ)     = 0
mprotect(0x403000, 4096, PROT_READ)     = 0
mprotect(0x266000, 4096, PROT_READ)     = 0
munmap(0xb8005000, 99174)               = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
rt_sigaction(SIGINT, {0x804d0e0, [INT], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x804d0e0, [TERM], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGHUP, {0x804d0e0, [HUP], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {0x804d0e0, [PIPE], SA_RESTART}, {SIG_DFL}, 8) = 0
stat64("/var/run/gdm/auth-cookie-XXO41A9T-for-tbl-c", 0xbfe1a9c4) = -1 ENOENT
(No such file or directory)
open("/var/run/gdm/auth-cookie-XXO41A9T-for-tbl-c", O_WRONLY|O_CREAT|O_EXCL,
0600) = -1 EACCES (Permission denied)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, {2, 0})               = 0
open("/var/run/gdm/auth-cookie-XXO41A9T-for-tbl-c", O_WRONLY|O_CREAT|O_EXCL,
0600) = -1 EACCES (Permission denied)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, {2, 0})               = 0
open("/var/run/gdm/auth-cookie-XXO41A9T-for-tbl-c", O_WRONLY|O_CREAT|O_EXCL,
0600) = -1 EACCES (Permission denied)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, {2, 0})               = 0
open("/var/run/gdm/auth-cookie-XXO41A9T-for-tbl-c", O_WRONLY|O_CREAT|O_EXCL,
0600) = -1 EACCES (Permission denied)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, {2, 0})               = 0
open("/var/run/gdm/auth-cookie-XXO41A9T-for-tbl-c", O_WRONLY|O_CREAT|O_EXCL,
0600) = -1 EACCES (Permission denied)

So looks like xauth can't create lock file in /var/run/gdm and times out.

[root@localhost gdm]# ls -ld /var/run/gdm
drwxr-xr-t 2 root gdm 4096 2008-04-11 08:45 /var/run/gdm
[root@localhost gdm]# ls -ldZ /var/run/gdm
drwxr-xr-t  root gdm system_u:object_r:xdm_var_run_t  /var/run/gdm
[root@localhost gdm]#
Comment 5 Tom London 2008-04-11 18:12:03 UTC 
Making /var/run/gdm writable by 'other' makes 'su -l' complete almost instantly.

So what's the right way to allow xauth to write the lock file?
Comment 6 Ray Strode [halfline] 2008-04-11 19:13:20 UTC 

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