Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1923086 - Change user via "su" takes 20 to 60 second become root
Summary: Change user via "su" takes 20 to 60 second become root
Status: CLOSED DUPLICATE of bug 1922772
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 33
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2021-02-01 12:00 UTC by Onuralp SEZER
Modified: 2021-02-01 23:53 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-02-01 23:53:04 UTC
Type: Bug

Attachments (Terms of Use)
strace log (66.07 KB, text/plain)
2021-02-01 16:21 UTC, Onuralp SEZER
no flags Details
Result of strace -o su.log --relative-timestamps -p PID (47.29 KB, text/plain)
2021-02-01 17:26 UTC, Matthew Cline
no flags Details

Description Onuralp SEZER 2021-02-01 12:00:21 UTC
Version-Release number of selected component (if applicable):

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:

Comment 1 Karel Zak 2021-02-01 14:20:05 UTC
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

Comment 2 Onuralp SEZER 2021-02-01 16:21:25 UTC
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

Comment 3 Matthew Cline 2021-02-01 17:26:16 UTC
Created attachment 1753999 [details]
Result of strace -o su.log --relative-timestamps -p PID

Comment 4 Matthew Cline 2021-02-01 17:59:17 UTC
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"

Comment 5 Matthew Cline 2021-02-01 20:52:22 UTC
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.

Comment 6 Onuralp SEZER 2021-02-01 20:56:54 UTC

It must be related with this then ?

Comment 7 Garry T. Williams 2021-02-01 21:15:07 UTC
(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.

Comment 8 Rex Dieter 2021-02-01 23:53:04 UTC

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

Note You need to log in before you can comment on or make changes to this bug.