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
| Summary: | SSH and SU slow because of xauth permission issue under SDDM | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paul Black <paul.0000.black> |
| Component: | sddm | Assignee: | Martin Bříza <m> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 33 | CC: | bartos.petr, jgrulich, kde-sig, kwolf, me, m, mwoodson, pgnet.dev, pierluigi.fiorini, rdieter, thunderbirdtr, tmvolin |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | |
| Embargoed: | |||
|
Description
Paul Black
2021-01-31 14:38:04 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. 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. *** Bug 1923234 has been marked as a duplicate of this bug. *** 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.
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
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. *** Bug 1923086 has been marked as a duplicate of this bug. *** 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. 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. 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. *** Bug 1924008 has been marked as a duplicate of this bug. *** FYI, pulled in the /run/sddm permissions adjustments to future-proof this better, https://src.fedoraproject.org/rpms/sddm/c/ad6c2436c00056e9977049b6bc519a39db9e0663?branch=rawhide 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. 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) |