Bug 1187957
| Summary: | KDM writing incorrect XAUTHORITY file for XDMCP sessions | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ian Pilcher <ipilcher> |
| Component: | kde-workspace | Assignee: | Rex Dieter <rdieter> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 21 | CC: | ipilcher, jgrulich, jreznik, kevin, mbriza, rdieter, rnovacek, than |
| Target Milestone: | --- | Keywords: | Patch |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-12-02 08:22:29 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: | |||
| Attachments: | |||
Created attachment 986576 [details]
systemd service file for remote VNC connection
Created attachment 986577 [details]
kdmrc file, with XDMCP enabled
xdm_write_home is set (sudo setsebool -P xdm_write_home on) I did some more poking at this, and it looks like the problem is the contents of the XAUTHORITY file, rather than the value of DISPLAY.
When I first connect to Xvnc, and the KDM greeter is displayed, I can see (in /proc/${KDM_GREET_PID}/environ) that it has the following environment variables:
DISPLAY=:10
XAUTHORITY=/var/run/kdm/Alocalhost:10-IN7uFb
Using these values (and running as root), xdpyinfo is able to connect to the X server.
If I log in, I can see that the variables in the user session are let like this:
DISPLAY=:10
XAUTHORITY=/tmp/.XauthykCDob
With this XAUTHORITY file, xdpyinfo is unable to connect to Xvnc (as either root or the logged in user):
No protocol specified
xdpyinfo: unable to open display ":10".
If I (as root) copy the XAUTHORITY file from /var/run/kdm to /tmp and make it readable by the logged in user, I can use that XAUTHORITY file to connect to Xvnc.
Here is the working XAUTHORITY file from /var/run/kdm:
00000000 ff ff 00 00 00 00 00 12 4d 49 54 2d 4d 41 47 49 |........MIT-MAGI|
00000010 43 2d 43 4f 4f 4b 49 45 2d 31 00 10 5c 00 e6 dd |C-COOKIE-1..\...|
00000020 8f c9 d1 97 2f 80 82 e7 d5 27 2a 03 |..../....'*.|
0000002c
And here is the non-working XAUTHORITY file that KDM wrote in /tmp:
00000000 00 06 00 10 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 01 00 02 31 30 00 12 4d 49 54 2d 4d 41 |......10..MIT-MA|
00000020 47 49 43 2d 43 4f 4f 4b 49 45 2d 31 00 10 5c 00 |GIC-COOKIE-1..\.|
00000030 e6 dd 8f c9 d1 97 2f 80 82 e7 d5 27 2a 03 |....../....'*.|
0000003e
Working: # xauth -f /var/run/kdm/Alocalhost:10-IN7uFb list #ffff##: MIT-MAGIC-COOKIE-1 5c00e6dd8fc9d1972f8082e7d5272a03 Non-working: # xauth -f /tmp/.XauthykCDob list localhost:10 MIT-MAGIC-COOKIE-1 5c00e6dd8fc9d1972f8082e7d5272a03 Could you attach the contents of /etc/kde/kdm/kdmrc ? Created attachment 988689 [details]
kdmrc
Attaching requested kdmrc file. (It was already attached, but this one is literally the stock kdmrc installed by the kde-settings-kdm RPM with XDMCP enabled.)
Though your description seems to match the default configuration: # Where to put the user's X-server authorization file if ~/.Xauthority # cannot be created. # Default is "/tmp" #UserAuthDir= # If true, UserAuthDir will be used unconditionally. # Default is false ForceUserAuthDir=true I'm at a loss why it doesn't work when in /tmp though. I wonder if selinux or systemd privatetmp features may be getting in the way here? If so, we could consider moving the default location, to say, something like: /var/run/user/$USER_ID/ I just tried setting ForceUserAuthDir=false. The XAUTHORITY file is now created in ~/.Xauthority, but everything else is still the same. (The display name in ~/.Xauthority is localhost:10, and it X clients using that file are unable to connect to :10.) I also tried with SELinux in permissive mode; again no joy. Looks like the proper display name for the XAUTHORITY file is ${HOSTNAME}/unix:${DISPLAY_NUMBER}. This is what KDM uses for local X servers that it starts.
Created attachment 989090 [details]
Make KDM recognize IPv6 loopback addresses
So I found the problem. KDM apparently special-cases "remote" displays across the loopback address, but the code which recognizes the loopback IP (convertAuthAddr in kdm/backend/auth.c) was never updated to recognize IPv6 loopback addresses -- ::1 and potentially ::ffff:127.0.0.1. (And it's pretty much impossible to avoid an IPv6 connection these days without disabling it system-wide.)
With this patch, the user session is able to connect to the Xvnc server.
Thanks, excellent detective-work! I'll try to integrate the patch for a test build soon. Created attachment 989261 [details] Make KDM recognize IPv6 loopback addresses - v2 Here's an updated version of the patch that is (hopefully) a bit more idiomatic. Just for grins, here is the original KDE bug which was fixed for IPv4 only: https://bugs.kde.org/show_bug.cgi?id=44859 Test builds (may need other kde stuff from updates-testing though): F-21: http://koji.fedoraproject.org/koji/buildinfo?buildID=609668 F-20: http://koji.fedoraproject.org/koji/buildinfo?buildID=609669 (In reply to Rex Dieter from comment #14) > Test builds (may need other kde stuff from updates-testing though): > > F-21: > http://koji.fedoraproject.org/koji/buildinfo?buildID=609668 > > F-20: > http://koji.fedoraproject.org/koji/buildinfo?buildID=609669 F21 build appears to work. This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 986575 [details] systemd socket file for remote VNC connection Description of problem: Trying to set up remote access to my workstation via Xvnc, KDM, and XDMCP. I have Xvnc talking to KDM and displaying the greeter, and I am able to successfully log in. Once logged in, however, the user session is unable to connect to the X server (Xvnc). For example: No protocol specified xrdb: Resource temporarily unavailable xrdb: Can't open display ':10' No protocol specified xmodmap: unable to open display ':10' No protocol specified The same setup works with LightDM. The most obvious difference between the (working) LightDM session and the (non-working) KDM session is the value of the DISPLAY variable. LightDM sets DISPLAY to 172.31.248.2:10.0, where KDM sets it to :10. (172.31.248.2 is one of the IP addresses on this system.) Version-Release number of selected component (if applicable): kdm-4.11.14-3.fc21.x86_64 How reproducible: 100% Steps to Reproduce: 1. Configure remote access via Xvnc, KDM, and XDMCP 2. Connect via VNC 3. Log in Actual results: User session dies immediately and closes VNC connection. Expected results: Working desktop session.