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 1922772

Summary: SSH and SU slow because of xauth permission issue under SDDM
Product: [Fedora] Fedora Reporter: Paul Black <>
Component: sddmAssignee: Martin Bříza <m>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 33CC: bartos.petr, jgrulich, kde-sig, kwolf, me, m, mwoodson,, pierluigi.fiorini, rdieter, thunderbirdtr, tmvolin
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: sddm-0.19.0-6.fc33 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-03 01:55:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Paul Black 2021-01-31 14:38:04 UTC
Description of problem:
Today I've noticed that SSH with X11 forwarding enabled is slow to login. It seems the problem lies with xauth not being able to read a file in /var/run/sddm. The file is specified in the XAUTHORITY env variable.

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1. time xauth list < /dev/null

Actual results:
xauth:  timeout in locking authority file /var/run/sddm/xauth_tAKhNT
xauth list < /dev/null  0.00s user 0.00s system 0% cpu 20.006 total

Expected results:
[ Obtained by removing XAUTHORITY env variable ]
Using authority file /home/paul/.Xauthority
xauth < /dev/null  0.00s user 0.00s system 90% cpu 0.005 total

Additional info:
# sudo su
# ls -ald /var/run/sddm
drwx--x--x. 2 root root 80 Jan 31 14:33 /var/run/sddm
# ls -ald /var/run/sddm/xauth_tAKhNT 
-rw-------. 1 paul paul 104 Jan 31 08:23 /var/run/sddm/xauth_tAKhNT

Something in this commit?

Comment 1 Troy Volin 2021-01-31 22:41:02 UTC
You beat me to it.
I noticed THIS in the sddm RPM changelog so I think this is very recent (the NOSPAM is mine)
* Tue Jan 26 2021 Rex Dieter <rdieter> - 0.19.0-4
- Refresh Xauth patch from upstream PR

Behavior is very strange. previously, XAUTHORITY would be set to /tmp/xauth-nnnn-_0  (where nnnn is your uid, like 1000)
Interestingly with the latest sddm change that file is still created, and has same contents as /var/run/sddm/xauth_FoObAr
But to create the lock, xauth wants to create a file with "-c" tacked to the end of the filename, but it is not allowed to write in directory /var/run/sddm/

It's unfortunate because this is all so unnecessary. with xhost showing "SI:localuser:tvolin" the spoofed xauth info that ssh makes (after xauth times out) works just fine and always will.

Comment 2 Troy Volin 2021-01-31 23:04:20 UTC
I have reported this upstream:
I did not bother to open an issue upstream, but I suppose I should.

Comment 3 Rex Dieter 2021-02-01 16:50:33 UTC
*** Bug 1923234 has been marked as a duplicate of this bug. ***

Comment 4 2021-02-01 17:54:25 UTC
F33 as well, here; ~ 30+ second delay on login.  runlevel3 & XFCE are ok.

brute-forcing here, 

ls -ald /var/run/sddm
	total 8.0K
	drwx--x--x  2 root    root      80 Feb  1 12:10 ./
	drwxr-xr-x 48 root    root    1.4K Feb  1 12:12 ../
	-rw-r--r--  1 sddm    sddm     118 Feb  1 12:10 {4a295417-7fa2-434e-8c7d-e31e0d65a5d9}
	-rw-------  1 pgnd    pgnd     118 Feb  1 12:10 xauth_aVkWUM

chmod 777 /var/run/sddm

'cures' the issue.  delay's gone.

Comment 5 Bob Richmond 2021-02-01 22:19:59 UTC
Seconded, as of 0001-Redesign-Xauth-handling.patch, the xauth cookie is now written to /var/run/sddm instead of ~/.Xauthority and it's exporting the XAUTHORITY environment variable to point to the created temporary filename that is now located in the /var/run/sddm directory. runs "xauth -f ${XAUTHORITY} nlist :0" which in turn calls XauLockAuth with the given filename. XauLockAuth then tries to create "${XAUTHORITY}-c" and "${XAUTHORITY}-l" up to XAUTH_DEFAULT_RETRIES times (10) with XAUTH_DEFAULT_TIMEOUT (2) seconds in between, but /var/run/sddm ships with mode 0711/root/root, so it can't create these files as non-root, as you could in your own home directory as it used to be. It seems like /var/run/sddm should be more like /tmp. Suggest chmod 1733 /var/run/sddm

Comment 6 Troy Volin 2021-02-01 22:36:13 UTC
I agree. changing /usr/lib/tmpfiles.d/sddm.conf so it creates the directory with 1733 instead of 0711 would work, and seems appropriate.
I will do that locally for now (in /etc/tmpfiles.d/sddm.conf), but I think that should be passed up the line to or possibly an issue there as well. it's their baby.

Comment 7 Rex Dieter 2021-02-01 23:53:04 UTC
*** Bug 1923086 has been marked as a duplicate of this bug. ***

Comment 8 Fedora Update System 2021-02-02 02:19:56 UTC
FEDORA-2021-ff5077524e has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ff5077524e`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 9 Troy Volin 2021-02-02 13:20:58 UTC
Upstream comment thread points out that Mandriva addresses this downstream (with permissions).
I think we should take Bob Richmond's suggestion for /use/lib/tmpfiles.d/sddm.conf here in Fedora packaging.
Update, I see Rex is rolling back the xauth change, so I guess it's a non-issue.

Comment 10 Fedora Update System 2021-02-03 01:55:14 UTC
FEDORA-2021-ff5077524e has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 11 Rex Dieter 2021-02-03 16:03:38 UTC
*** Bug 1924008 has been marked as a duplicate of this bug. ***

Comment 12 Rex Dieter 2021-02-03 16:09:48 UTC
FYI, pulled in the /run/sddm permissions adjustments to future-proof this better,

Comment 13 Rex Dieter 2021-02-03 16:12:12 UTC
Fwiw, openmandriva uses 1777 perms, while Bob recommended 1733

I opted to follow openmandriva's lead for now, but I'm open to changing.
I'd like to hear folks' pros/cons opinions on the matter.

Comment 14 Rex Dieter 2021-02-03 16:14:01 UTC
Just read the dialog in the upstream sddm issue, and the consensus there was that 1733 was superior to 1777, so I'll go ahead and go with that instead (sorry for the sddm bug spam)