Version-Release number of selected component (if applicable): util-linux-2.36-3.fc33.x86_64 util-linux-user-2.36.1-1.fc33.x86_64 I tested with both How reproducible: Steps to Reproduce: 1. open terminal type su - 2. type password 3. approx wait 20-60 second (I used default bash/env variables) Actual results: It should be root instantly Expected results: 20-60 second to become root (depends on hardware I believe) Additional info:
I cannot reproduce this problem. Please, try to debug it with another terminal by strace command. * login as root on the first terminal * login as user on the second terminal, and start "su -", don't type root password * move to the first terminal (root), get PID of su(1) -- for example "pidof su" * start "strace --log /root/su.log --relative-timestamps -p <PID>" * move to the second terminal (su) and type password * provide /root/su.log
Created attachment 1752891 [details] strace log I uploaded log and I had to change command to; strace -o su.log --relative-timestamps -p <pid> because "--log" didn't exist
Created attachment 1753999 [details] Result of strace -o su.log --relative-timestamps -p PID
Some notes on what I've observed: 1) This happens regardless of whether su starts a login shell (that is, it also happens without the "-" or "-l" command line options) 2) This happens for both su'ing to my root account (with a password) and su'ing to some special non-root accounts which have no passwords. 3) There is no delay if I do "sudo /bin/bash" 4) If I have journalctl open in follow mode ("-f"), then as soon as the password is entered it immediately shows: > su[PID]: pam_unix(su-l:session): session opened ... However, auditd doesn't spit out anything until the su finished and I get a bash prompt, at which point it spits out > audit[PID]: USER_START ... And there's nothing between those two lines of output from journalctl 5) Temporarily disabling auditing has no effect. 6) Logging in as root from a virtual console has no delay. 7) Nothing is changed if I force the regeneration of pam files via "authselect select --force minimal with-ecryptfs" 8) Nothing is changed if I remove the automounting of ecryptfs via "authselect select --force minimal"
Upon further investigation the problem has something to do with xauth, sddm and permissions/ownership. In my su.log the delay seems to be the 20 seconds between a read and a SIGCHLD where si_uid=1000. I re-did the strace with an added "-f" to strace (so it also traced children) and looked at what happened right before the relevant SIGCHLD, and saw > write(2, "/usr/bin/xauth: timeout in lock"..., 78) = 78 I tried running xauth as user 1000, and it hung for about 20 second before giving: > xauth: timeout in locking authority file /var/run/sddm/xauth_fYknZz /var/run is just a symlink to /run, so looking at /run/sdddm I saw that the directory had owner and group "root" with a permission of 711 (drwx--x--x) while /run/sddm/xauth_fYknZz had owner and group 1000 . I chmodded /run/sddm to to 777, after which both xauth and "su -l root" ran with no delay. So the problem seems to be that something is changing ownership and/or permissions of /run/sddm.
https://bugzilla.redhat.com/show_bug.cgi?id=1922772 It must be related with this then ?
(In reply to Matthew Cline from comment #5) > I chmodded /run/sddm > to to 777, after which both xauth and "su -l root" ran with no delay. Interestingly, 0755 would not help. Write permissions are needed to cure the delay. But the files in /run/sddm were not updated after the su command was completed without delay.
*** This bug has been marked as a duplicate of bug 1922772 ***