Move Xauthority to a different location and truncate it again #947
Conversation
When the hostname changes, started X applications try the new hostname first. If a cookie is found for that new hostname, they try to authenticate (which fails) and exit. So .Xauthority must not contain old cookies. Truncating ~/.Xauthority breaks ssh forwarding though, so the default location is changed to something sddm specific. As it's not possible to login twice as the same user simultaneously, a fixed path at a fixed location is enough. Issue sddm#944
|
For reference, downstream bugreport about truncating .Xsession breaking ssh -X: https://bugzilla.suse.com/show_bug.cgi?id=1043221 |
| @@ -65,7 +65,7 @@ namespace SDDM { | |||
| Entry(SessionDir, QString, _S("/usr/share/xsessions"), _S("Directory containing available X sessions")); | |||
| Entry(SessionCommand, QString, _S(SESSION_COMMAND), _S("Path to a script to execute when starting the desktop session")); | |||
| Entry(SessionLogFile, QString, _S(".local/share/sddm/xorg-session.log"), _S("Path to the user session log file")); | |||
| Entry(UserAuthFile, QString, _S(".Xauthority"), _S("Path to the Xauthority file")); | |||
| Entry(UserAuthFile, QString, _S(".local/share/sddm/.Xauthority"), _S("Path to the Xauthority file")); | |||
There was a problem hiding this comment.
Instead of hardcoding ~/.local/share/ - shouldn't this be determined through QStandardPaths::DataLocation?
There was a problem hiding this comment.
It's the same directory as the logfile location entry, which is hardcoded as well.
There was a problem hiding this comment.
it's configurable it's not hard-coded
There was a problem hiding this comment.
I mean that the default value is hardcoded.
Vogtinator
changed the title
|
I got some positive user feedback, so I removed the WIP flag. |
|
fyi, pull request 863 (Use libXau instead of xauth), will probably solve the problem outlined here too |
It doesn't, there's no difference between xauth and libXau in that regard. Whether you call an external program to assemble the cookie or a lib doesn't matter. To really fix the hostname issue, libxcb needs to be patched like done in openSUSE: https://build.opensuse.org/package/view_file/home:michalsrb:branches:X11:XOrg/libxcb/n_If-auth-with-credentials-for-hostname-fails-retry-with-XAUTHLOCALHOSTNAME.patch?expand=1 |
|
libXau's support for FamilyWild should be (more) resilient to hostname changes (it is for me). For more background, see comments from one of gdm's maintainers: https://bugzilla.redhat.com/show_bug.cgi?id=1370222#c25 Anyway, pull request 863 is one baby step toward resolving #733 If that's not what you're talking about, pardon my comments |
It kind of is. This needs to be merged or FamilyWild will just break as more than one FamilyWild entry does not make sense. |
|
I'll close this now - this was only a workaround for a bug in libxcb. |
When the hostname changes, started X applications try the new hostname
first. If a cookie is found for that new hostname, they try to authenticate
(which fails) and exit. So .Xauthority must not contain old cookies.
Truncating ~/.Xauthority breaks ssh forwarding though, so the default
location is changed to something sddm specific.
As it's not possible to login twice as the same user simultaneously,
a fixed path at a fixed location is enough.
Issue #944