GNOME Bugzilla – Bug 690926
reauthentication breaks XDMCP
Last modified: 2013-11-04 23:46:46 UTC
Yesterday I installed Fedora 18's beta and configured it as an XDMCP server for an X11 terminal running CentOS 6. The terminal will display the GDM login screen, but entering a username causes the interface to stop working. The username will remain displayed, and the buttons will animate when clicked, but no login is apparently attempted. It looks like the problem is caused by the reauthentication support added in commit 2853ce5812aa8f03f677516e64d5dcff1e6e01ab. GDM logs an exception and the error "Error getting session ids from systemd: No such file or directory". I think there are three problems here. First, glib is warning that GError isn't being set correctly. GDM's exception and subsequent unresponsiveness may be a result of that, or a bug of it's own. I'm not sure. The big problem, though, is that as of that commit, GDM seems to require multiseat information from the X11 servers. That requirement doesn't seem to make sense in XDMCP mode, but no fallback appears to be present. Assuming that is the case, could someone either implement an alternate path for XDMCP so that the greeter doesn't crash, or disable XDMCP support when the system is built WITH_SYSTEMD? If XDMCP isn't going to work, it'd be far preferable for GDM to simply log that it cannot enable XDMCP when built WITH_SYSTEMD than it is to enable XDMCP and subsequently fail. Thanks. Version: gdm-3.6.2-5.fc18.x86_64 Commit: https://mail.gnome.org/archives/commits-list/2012-July/msg04426.html Logs: ==> messages <== Dec 23 17:38:05 herald gdm[2173]: gdm-binary[2173]: GLib-WARNING: GError set over the top of a previous GError or uninitialized memory. Dec 23 17:38:05 herald gdm[2173]: This indicates a bug in someone's code. You must ensure an error is NULL before it's set. Dec 23 17:38:05 herald gdm[2173]: The overwriting error message was: Error getting session ids from systemd: No such file or directory Dec 23 17:38:05 herald gdm-binary[2173]: GLib-WARNING: GError set over the top of a previous GError or uninitialized memory. ==> gdm/192.168.89.1:0-greeter.log <== JS ERROR: !!! Exception was: TypeError: Object 0x7fdf06b41ec8 is not a subclass of (null), it's a GLib_Error JS ERROR: !!! message = '"Object 0x7fdf06b41ec8 is not a subclass of (null), it's a GLib_Error"' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/gdm/util.js"' JS ERROR: !!! lineNumber = '159' JS ERROR: !!! stack = '"([object _private_Gdm_Client],[object _private_Gio_SimpleAsyncResult])@/usr/share/gnome-shell/js/gdm/util.js:159 wrapper([object _private_Gdm_Client],[object _private_Gio_SimpleAsyncResult])@/usr/share/gjs-1.0/lang.js:204"'
Created attachment 236946 [details] [review] daemon: bail if unable to get seat from pid If we can't get the seat from the pid during reauthentication, then we need to bail right away, or we'll end up failing on the next call and overwriting the already written error.
Comment on attachment 236946 [details] [review] daemon: bail if unable to get seat from pid (pushing this for now, but probably need to do more extensive XDMCP testing and fixes still) Attachment 236946 [details] pushed as 5ebfd52 - daemon: bail if unable to get seat from pid
I hit this today while testing Fedora 19. The current status seems to be that the gdm daemons survive, but the javascript code flames out if no seat id can be found.
Created attachment 242631 [details] [review] Patch that improves the situation. This patch solves the immediate problem at hand. gnome-shell catches a limited set of errors, and expects ACCESS_DENIED if there is trouble getting seat or session information. For a session started with xdmcp (or really, any session without a seat), you would always trigger this case, and gnome shell doesn't handle the resulting GDM_DISPLAY_ERROR_GETTING_SESSION_INFO.
So gdm-slave is really pretty uptight about having a seat id; your next error is this from gdm-slave.c: display seat ID is not set; can't switch sessions I didn't seen an obvious path to proceed without a seat ID; that may be mostly my lack of experience with that code. Further, the Xorg '-seat' flag is structured such that you can only assign a seat to a device that has a platformProbe method. This means that current dummy drivers (and the qxl driver, my interest) cannot specify a seat. The same is probably true for dumb X terminals (the other typical use case for XDMCP). So, effectively, gdm is unable to do xdmcp, by current design. Someone very familiar with the current gdm-slave code may be better able than I am to more surgically handle the 'no seat id' case and make a path for that. Alternately, perhaps we should just strip xdmcp support from gdm; a lack of general outcry suggests that few people use the feature, and it might be better to not advertise a feature that isn't going to work.
Created attachment 258684 [details] [review] manager: return ACCESS DENIED for most open-reauth-channel failures gnome-shell only falls back to opening a new session if the reauth channel fails to open because of denied access. For XDMCP we currently fail for other reasons. This commit returns ACCESS DENIED for those cases as well, so the intended fallback happens.
Created attachment 258685 [details] [review] slave: don't kill slave when client disconnects Right now we stop the slave if a greeter running on a remote X server exits. This is wrong, since the greeter will exit as part of the login screen process. We already have mechanisms in place to reap the slave at the appropriate time, so stopping the slave on disconnection is totally unneeded and actively harmful. This commit drops that code.
These two patches fix the issue for me. attachment 258684 [details] [review] is basically the same as attachment 242631 [details] [review] (which I forgot you attached, and just noticed when looking for the bug report to attach these patches)
Attachment 258684 [details] pushed as ae7beb6 - manager: return ACCESS DENIED for most open-reauth-channel failures Attachment 258685 [details] pushed as 82296a3 - slave: don't kill slave when client disconnects
(still need to fix the unlock screen, so reopening)
Thanks for looking into this. Can you hit me with a clue bat on the connection between this issue and the disconnect patch you applied?
Created attachment 258781 [details] [review] daemon: don't require seat to locate reauth channel With systemd, XDMCP sessions don't have associated seats. Currently, reauth channels find the session by first looking up the seat, which means unlocking fails for XDMCP. This commit changes the code to determine session strictly from pid.
Created attachment 258782 [details] [review] slave: Pass session id to unlocking code if we know it We currently figure out which session to unlock on-the-fly based on the username that was just reauthenticated. This doesn't work, for XDMCP sessions, under logind, since they don't have a seat. There's no reason to try to deduce the session, though. We already know it, so we might as well pass it down. This fixes unlocking for XDMCP.
Attachment 258781 [details] pushed as 0411653 - daemon: don't require seat to locate reauth channel Attachment 258782 [details] pushed as 74e4b08 - slave: Pass session id to unlocking code if we know it
(In reply to comment #11) > Thanks for looking into this. Can you hit me with a clue bat on the connection > between this issue and the disconnect patch you applied? Basically, the login screen disconnects from the gdm slave process after the user types their password (since the login screen exits, in preparation for starting the user session). When this disconnection happens, we shouldn't clean up the slave, since the slave needs to exists for the duration of the user's session.
This worked for me with Xspice, but not with Xephyr or Xnest. Also, note that there was another related patch committed: https://git.gnome.org/browse/gdm/patch/?id=02ddd7ea077c990d9dc2f0cb87a500fc20b0c0bb but not listed on this bug. I mention it for completeness.
make sure your Xephyr has this commit: http://cgit.freedesktop.org/xorg/xserver/commit/hw/kdrive/ephyr?id=ceffb34774d44ada83cc1994d20c8d65b46bd555 I don't think Xnest will work since I don't think it supports GLX