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:
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 ~]#
[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?
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
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]#
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?
*** This bug has been marked as a duplicate of 442061 ***