summaryrefslogtreecommitdiff
path: root/daemon/gdm-manager.c
Commit message (Collapse)AuthorAgeFilesLines
...
* daemon/gdm-manager.c: quit plymouth when xdmcp is the only allowed connection.Yifan J2018-04-101-0/+7
| | | | | | | | | | | | | | | | | | | | | | | gdm is responsible to kill plymouth by spawning the "plymouth quit" subprocesses in gdm-manager.c. The current code pathes of quiting plymouth can never be reached when xdmcp is the only connection allowed. Consequently in the case of !show_local_greeter && xdmcp_enabled the plymouth-quit-wait.service will never quit and the login prompt will not popup without manual interference. This issue could be more obviously observed when a downstream like openSUSE which allows a customized sysconfig to switch the corresponding two options on a headless server (s390), where the setup is usually: DISPLAYMANAGER_REMOTE_ACCESS="yes" DISPLAYMANAGER_STARTS_XSERVER="no" The proposed patch handles this edge case by quit plymouth immediately when the condition is detected. https://bugzilla.gnome.org/show_bug.cgi?id=795120
* Remove unused variablesRobert Ancell2018-01-101-2/+0
|
* manager: fix compile warningRay Strode2017-10-131-2/+2
| | | | | | | | | | commit 7e8243eecd0233f7ab92519207f2520794439b11 introduced a compiler warning if gdm is built with --enable-wayland and --disable-user-display-server This commit fixes that. https://bugzilla.gnome.org/show_bug.cgi?id=788963
* manager: don't record wtmp entries when user unknownRay Strode2017-10-101-0/+5
| | | | | | | | | | | | | Right now we end up writing wtmp entries for the login screen user into /var/log/wtmp, but with a funky username of "(unknown)". The login screen session shouldn't get a wtmp entry, and we shouldn't ever add wtmp entries for sessions we don't know the username for. This commit fixes that. https://bugzilla.gnome.org/show_bug.cgi?id=788784
* Use standard exit codes.Robert Ancell2017-10-031-2/+2
| | | | | | | | | Use EXIT_ defines for readibility. There were some exit codes > 1, but they don't seem to be checked by any of the parent process code. This does mean that the logs might have changed, but modern logging techniques have probably made this obsolete. https://bugzilla.gnome.org/show_bug.cgi?id=788307
* daemon,libgdm: allow wayland sessions with --disable-user-display-serverRay Strode2017-09-191-1/+1
| | | | | | | | | | | | Right now we hide wayland sessions from the list if the greeter isn't wayland. The greeter is never wayland if built with --disable-user-display-server. This commit allows wayland sessions for the user session, when --disable-user-display-server --enable-wayland-support is specified, even though the greeter won't use wayland itself. https://bugzilla.gnome.org/show_bug.cgi?id=787899
* manager: don't allow autologin from transient displaysRay Strode2017-09-121-1/+4
| | | | | | | | | | | | | | | In theory, we're only only supposed to allow autologin the first time a session is run, but we only count a session run, once it's finished. This means that if a user creates a transient session to user switch, before they've logged out the first time at boot up, that transient session will begin autologin as well (which actually gets treated as an auto unlock). This commit makes sure autologin is only ever run on the initial display. https://bugzilla.gnome.org/show_bug.cgi?id=783779
* manager: fix dangling pointer freeRay Strode2017-08-231-1/+1
| | | | | | | | | | | | When reauthenticating, we can crash if no login screen is running on the seat (for instance, when building with --disable-user-display-server, and not user switching). The crash is due to a dangling pointer. This commit fixes that. https://bugzilla.gnome.org/show_bug.cgi?id=786656
* manager: make sure a session's display knows about the sessionRay Strode2017-08-181-1/+6
| | | | | | | | | | | | When logging into a session that runs on another VT, we create a new display object for it. That display object needs to know about the session, so we can find the session when reauthenticating against the display. The code that links the two together was missing. This commit adds it. https://bugzilla.gnome.org/show_bug.cgi?id=784555
* manager: rename embryonic-user-session to user sessionRay Strode2017-08-181-18/+18
| | | | | | | | | | | The user session exists and gets used after it's fully grown, (when reauthenticating), so calling it an embryonic session is weird. The word embryonic is weird anyway. Previously, we called it a seed session, and that was weird, too, for the same reason. Before that we just called it a user session, so let's come around full circle and name it user session again. https://bugzilla.gnome.org/show_bug.cgi?id=784555
* manager: rename get_user_session_for_display to find_user…Ray Strode2017-08-181-3/+3
| | | | | | | This function iterates through a list so calling the action find is more appropriate. https://bugzilla.gnome.org/show_bug.cgi?id=784555
* manager: stop greeter explicitly when finishing displayRay Strode2017-05-081-0/+1
| | | | | | | | | | If GDM shuts down while the login screen is active, we fail to kill off the login screen session. This commit fixes that, by explicitly stopping the greeter session on the display (if there is one) https://bugzilla.gnome.org/show_bug.cgi?id=780213
* manager: update session-id property when reusing displayRay Strode2017-05-041-4/+8
| | | | | | | | | | | If a display starts out its life as a greeter display, and then gets reused for the user session, we need to update the session-id property on the display to match its new session. This is important so the reauthentication mechanism is able to match the session with existing display and run in the proper context. https://bugzilla.gnome.org/show_bug.cgi?id=782182
* manager: fix crash if session fails to startRay Strode2017-04-171-1/+2
| | | | | | | | | | commit 5c9e120594839b0597bc7bb8d06be7ba1076c0d8 attempts to handle a session failing to start, but messages up the signal prototype leading to crash. This commit fixes that. https://bugzilla.gnome.org/show_bug.cgi?id=781413
* manager: stop transient greeter session when done with itRay Strode2017-04-121-0/+20
| | | | | | | | | | | | | If we're running in legacy display mode, we currently can end up with a leaked greeter following user switching. That can happen if a user with an already running session is reauthenticated (so the login screen won't morph into the use session). This commit makes sure we kill the greeter session off in that case. https://bugzilla.gnome.org/show_bug.cgi?id=780939
* manager: make sure we end up on a login screenRay Strode2017-04-121-0/+128
| | | | | | | | | | | | | | | | If we're running in legacy mode where VT1 is not necessarily a login screen, then we can end up in a situation where logging out leaves us sitting on the wrong vt. 1) log in to user 1 on vt 1 2) switch user to login screen on vt 2 and log in as user 2 on vt 2 3) switch user to login screen on vt 3 and unlock user 1 back on vt 1 4) log out of user 1 on vt 1 5) now sitting at blank vt 1 This commit makes sure in that case we jump to a login screen https://bugzilla.gnome.org/show_bug.cgi?id=780914
* manager: add #ifdef HAVE_LIBXDMCP in a couple placesRay Strode2017-04-011-4/+11
| | | | | | | | | | | | | | halfline: gdm fails to build in Continuous: http://build.gnome.org/continuous/buildmaster/builds/2017/04/01/11/build/log-gdm.txt gdm-manager.o: In function `set_up_session': /ostbuild/source/gdm/_build/daemon/../../daemon/gdm-manager.c:1453: undefined reference to `gdm_xdmcp_chooser_display_get_type' gdm-manager.o: In function `gdm_manager_handle_open_session': /ostbuild/source/gdm/_build/daemon/../../daemon/gdm-manager.c:846: undefined reference to `gdm_xdmcp_chooser_display_get_type' https://bugzilla.gnome.org/show_bug.cgi?id=780813
* manager: fix up support for chooserRay Strode2017-03-311-9/+53
| | | | | | | | | | We were missing some chunks of code to handle dealing with the chooser. This commit adds in the necessary bits to start the chooser, and deal with the choice. https://bugzilla.gnome.org/show_bug.cgi?id=780787
* manager: drop some erroneous codeRay Strode2017-03-311-18/+0
| | | | | | | This is commit 82296a3350b64d0ed5ae3b9f6983466c60dd8a53 all over again. The code snuck back in during a refactor ! https://bugzilla.gnome.org/show_bug.cgi?id=780787
* manager: if falling back to X11 retry autologinRay Strode2017-03-251-3/+8
| | | | | | | | Right now, we get one shot to autologin. If it fails, we fall back to the greeter. We should give it another go if the reason for the failure was wayland fallback to X. https://bugzilla.gnome.org/show_bug.cgi?id=780520
* manager: be more robust against autologin having an invalid userMichael Catanzaro2017-03-101-30/+85
| | | | | | | If the configured autologin user does not exist, fall back to a greeter session. https://bugzilla.gnome.org/show_bug.cgi?id=695250
* manager: don't try to activate session if session not on seatRay Strode2017-03-031-4/+6
| | | | | | | | | | | If a session is not associated with a seat (because it's remote), then we shouldn't try to activate the session. Activating sessions, really only means anything on seat0 (where it means to change the active VT). This prevents premature failure before unlock on XDMCP. https://bugzilla.gnome.org/show_bug.cgi?id=779500
* manager: handle session failing to startRay Strode2017-03-031-0/+13
| | | | | | | | | Right now if a session fails really early in the start up process, we fail to handle it. This commit fixes that. https://bugzilla.gnome.org/show_bug.cgi?id=779498
* manager: make sure we retain ignore-wayland on second loginRay Strode2016-12-051-29/+14
| | | | | | | | | | | | | The intention of the code is to only allow wayland login for user sessions if the greeter session is also wayland. Right now, that intention is only honored the first time a user logs in. This commit corrects the problem, to make sure sure we always avoid wayland if the greeter session avoided wayland. https://bugzilla.gnome.org/show_bug.cgi?id=775659
* daemon: update X11DisplayName on register displayMathias Reck2016-11-101-1/+3
| | | | | | | | | When a display registered, the sessions 'display-name' was already updated. The displays 'x11-display-name' however was not, so I've just added that. Of course that also meant that the 'x11-display-name' could no longer be constructor only. https://bugzilla.gnome.org/show_bug.cgi?id=752341
* manager: fix small leakMichael Catanzaro2016-03-021-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=695250
* manager: make sure timed login conversation is startedRay Strode2016-02-241-0/+3
| | | | | | | | | At some point in a refactor we apparently stopped starting the PAM conversation used for timed login. This commit adds it back. https://bugzilla.gnome.org/show_bug.cgi?id=762635
* daemon: don't build wayland support when disabledFrederic Crozat2016-01-121-1/+11
| | | | | | | Ensure all wayland relevant code is disable when wayland is disabled at compile time. https://bugzilla.gnome.org/show_bug.cgi?id=760518
* manager: don't use wayland for autologin if wayland disabledRay Strode2015-11-091-2/+13
| | | | | | | | | | | | | These days we default to using wayland user sessions if the unless greeter isn't wayland. But in the case of automatic login there is no greeter. This commit makes automatic login ignore wayland sessions if wayland is disabled in the config file. This gives us symetry with the greeter case, and provides a way for users to opt out of wayland. https://bugzilla.gnome.org/show_bug.cgi?id=757715
* manager: filter out wayland user sessions if X11 login screenRay Strode2015-11-061-1/+15
| | | | | | | | | | We use wayland by default on the login screen, so if we're running in an X11 session, then the presumption is that we're incapable of using wayland. If we're incapable of using wayland sessions then we should ignore wayland sessions read from user configuration and fall back to non-wayland defaults. https://bugzilla.gnome.org/show_bug.cgi?id=757715
* manager: only claen up stub greeter display if it's actually a stubRay Strode2015-09-141-4/+6
| | | | | | | | | | | | | | | | commit 2774c7e43b9fdf5e5e59ef1f53ae7ba29f4aa23c fixed a leak in the case we're doing autologin, but it also unconditionally cleans up the display in the non-autologin case, too. At the moment, we don't want to clean up the greeter in that case, since it causes unnecessary flicker and slows down fast user switching. ( though this behavior may get changed again pending the outcome of bug 747339 ) This commit makes sure we only clean up the leaker greeter display, if there is a leaked greeter display (namely, the autologin case) https://bugzilla.gnome.org/show_bug.cgi?id=749418
* manager: make sure user session displays have a seat assignedRay Strode2015-09-101-0/+3
| | | | | | | | | | | The local display factory expects all displays it tracks to have a seat, and we're going to be tracking automatic login displays in the display factory in a subsequent commit. This commit makes sure the seat-id is properly set on automatic login display objects. https://bugzilla.gnome.org/show_bug.cgi?id=749418
* manager: fix display leakRay Strode2015-09-101-0/+4
| | | | | | | | | If we're doing autologin then we prepare a stub greeter display that we don't actually end up using. This commit makes sure the greeter display gets cleaned up so it doesn't stick around in the display store forever. https://bugzilla.gnome.org/show_bug.cgi?id=749418
* manager: don't muck with the session type and class of stub display (autologin)Ray Strode2015-09-101-3/+0
| | | | | | | | | | | | | | Normally at startup a display is created of class "greeter" for the login screen to use. That display isn't used in the case automatic login is enabled. There's some iffy code to try to change the class from "greeter" to "user" in the automatic login case. That code is wrong, because in the automatic login case a new display is created specifically for the user session. The greeter session is abandoned, instead of used, so mucking with it's class and type is wrong. This commit removes the code that does that mucking. https://bugzilla.gnome.org/show_bug.cgi?id=749418
* require logind supportRay Strode2015-06-121-178/+36
| | | | | | | Now that consolekit support is gone, this commit drops all the conditionalizing of logind support. https://bugzilla.gnome.org/show_bug.cgi?id=743940
* drop consolekit supportRay Strode2015-06-121-317/+0
| | | | | | It was deprecated in 3.16 to be removed in 3.18 https://bugzilla.gnome.org/show_bug.cgi?id=743940
* manager: fix monitor hotplug segfaultRichard Bradfield2015-05-271-4/+3
| | | | | | | | | | | | | | | commit e5a0e92f59e256edc6489f2234fbe54c25ba9743 introduced a way to find a user session associated with a display object. That function has a bug in it, where it skips every even registered user session because it follows the next pointer twice per iteration of the loop. This can cause a crash on monitor hotplug, and in other scenarios if there are an odd number of user sessions (since the terminating NULL will be even and skipped over). https://bugzilla.gnome.org/show_bug.cgi?id=749987
* manager: Don't double-free x11_display_nameJan Alexander Steffens (heftig)2015-04-161-3/+5
| | | | | | | | | | x11_display_name got freed twice here; once by g_variant_iter_loop and once by g_clear_pointer. Also break out of the loop early and use a non-copying format to avoid having to free anything. https://bugzilla.gnome.org/show_bug.cgi?id=747310
* manager: properly query display number when built without plymouthRay Strode2015-04-111-1/+2
| | | | | | | | | The code to query the display number of the display object is erroneously tucked away in guards. This leads to the display device getting queried prematurely. https://bugzilla.gnome.org/show_bug.cgi?id=747351
* session-record: support NULL display name if tty availableRay Strode2015-04-021-1/+1
| | | | | | | wayland sessions don't necessarily have a display name, so this commit just uses the display device instead. https://bugzilla.gnome.org/show_bug.cgi?id=747169
* manager: set display device on session object at registration timeRay Strode2015-04-021-2/+9
| | | | | | | | | | | | | | | | | | | | When the wayland server used at login time registers with GDM, GDM tries to write a wtmp session record for it. wtmp registration for wayland sessions shouldn't use $DISPLAY like X11 displays, since $DISPLAY isn't as core and meaningful to wayland displays. Instead it could probably use tty device, but the tty device isn't up to date. This commit makes sure the tty device is associated with the session object at registration time. A future commit will probably move the tty association code to gdm-session.c at session open time. https://bugzilla.gnome.org/show_bug.cgi?id=747169
* manager: gather tty of session when looking up other detailsRay Strode2015-04-021-3/+56
| | | | | | | We'll need the tty to give a reasonable wtmp record for wayland sessions. https://bugzilla.gnome.org/show_bug.cgi?id=747169
* manager: set display name on session object at registration timeRay Strode2015-04-021-0/+13
| | | | | | | | | | | | | | | | | | | When the X server used at login time registers with GDM, GDM tries to write a wtmp session record for it. Now that the X server is started in the session, we don't know the display name of the X server up front and so don't have the display name attached to the session object. The wtmp record writing code relies on getting the display name from the session object, and so it fails. We do know the display name at registration time, from the details passed to the registration function. This commit makes sure to attach the display name to the session object as soon as the display is registered before writing the wtmp record. https://bugzilla.gnome.org/show_bug.cgi?id=747169
* manager: find session at registration timeRay Strode2015-04-021-1/+26
| | | | | | | | | | | | | We try to look up the session at registration time to add wtmp records for it. We fail to actually find the session, though, because we're using the "embryonic-user-session" object data key, which is only non-NULL when the user session is still getting setup. This commit changes the registration code, to instead, fetch the session straight from the manager object. https://bugzilla.gnome.org/show_bug.cgi?id=747169
* manager: NULL unreferenced objects in disposeRay Strode2015-03-301-4/+7
| | | | | | | Now that we're using a dispose handler instead of a finalize handler, we need to make sure we nullify our objects after unrefing them. https://bugzilla.gnome.org/show_bug.cgi?id=745975
* manager: add a different hack to quit plymouth laterRay Strode2015-03-241-7/+19
| | | | | | | | | | | | | | Right now wayland sessions register with GDM before they're actually ready, so we quit plymouth too soon. Until we can fix that, this commit quits plymouth when the login screen connects to the daemon, or in the event of automatic login (where there is no login screen), after 20 seconds. This is like commit 862ba1bd67ec85b5784d3e8809a405f1845b1c43 but hopefully less broken.. https://bugzilla.gnome.org/show_bug.cgi?id=746498
* Revert "manager: add hack to quit plymouth after a delay"Ray Strode2015-03-241-1/+1
| | | | | | This reverts commit 862ba1bd67ec85b5784d3e8809a405f1845b1c43. https://bugzilla.gnome.org/show_bug.cgi?id=746498
* manager: add hack to quit plymouth after a delayRay Strode2015-03-191-1/+1
| | | | | | | | | | Right now wayland sessions register with GDM before they're actually ready, so we quit plymouth too soon. Until we can fix that, this commit adds a sleep 5 hack to quit plymouth a little after registration. https://bugzilla.gnome.org/show_bug.cgi?id=746498
* manager: don't block on plymouth quittingRay Strode2015-03-191-4/+2
| | | | | | | plymouth can quit in the background, the only thing we need to block synchronously on is it deactivating. https://bugzilla.gnome.org/show_bug.cgi?id=746498
* manager: move initial login handling to functionRay Strode2015-03-191-3/+14
| | | | | | | | | | | After the greeter is started, we may start any pending initial-setup login from the user. Right now we do that directly from on_display_status_changed. This commit moves the code off to a subroutine, since it's only going to get more complicated in the future. https://bugzilla.gnome.org/show_bug.cgi?id=746492