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 bugzilla.redhat.com.
Bug 1922772 - SSH and SU slow because of xauth permission issue under SDDM
Summary: SSH and SU slow because of xauth permission issue under SDDM
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sddm
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Bříza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1923086 1923234 1924008 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-01-31 14:38 UTC by Paul Black
Modified: 2021-02-03 21:20 UTC (History)
12 users (show)

Fixed In Version: sddm-0.19.0-6.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-03 01:55:14 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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):
sddm-0.19.0-5.fc33.x86_64


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:
$ echo $XAUTHORITY 
/var/run/sddm/xauth_tAKhNT
# 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? https://src.fedoraproject.org/rpms/sddm/c/771759b21908abfe3fba44d5c3883d0e5201eb0c?branch=master
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: https://github.com/sddm/sddm/pull/1230#issuecomment-770467367
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 pgnet.dev 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. pam_xauth.so 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 https://github.com/sddm/sddm/pull/1230 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: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ff5077524e

See also https://fedoraproject.org/wiki/QA:Updates_Testing 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.
Thanks.
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,
https://src.fedoraproject.org/rpms/sddm/c/ad6c2436c00056e9977049b6bc519a39db9e0663?branch=rawhide
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)
Note You need to log in before you can comment on or make changes to this bug.