summaryrefslogtreecommitdiff
path: root/daemon/gdm-manager.c
Commit message (Collapse)AuthorAgeFilesLines
* manager: Find user's current graphical session, not session of callerwip/benzea/systemd-userIain Lane2019-08-051-5/+6
| | | | | | | If (e.g.) gnome-shell is started as a systemd --user unit, it won't be part of the login session. We should instead look through all of the user's sessions until we find the login session, and take that as our session.
* GdmManager, GdmDisplay: Add RegisterSession methodIain Lane2019-05-291-0/+30
| | | | | Window managers can use this to register with GDM when they've finished starting up and started displaying.
* manager: don't return value from listify_display_idsRay Strode2019-02-211-4/+1
| | | | | | | | The manager code is returning FALSE from its listify_display_ids foreach function, which is useless since commit 47d01abe. This commit makes it return void instead.
* GdmManager: Don't perform timed login if session gets startedIain Lane2019-02-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | At the moment it's possible for the login screen to initiate a timed login operation shortly after a user successfully starts their session. GDM won't complete the timed login operation, since a session is already running, but will erroneously overwrite the username associated with the session, misattributing the users session to the timed login user. Later, attempts to log in as the timed user will instead unlock the session for the other user, since that session is now associated with the timed login user. This commit refuses timed login requests on sessions that are already running, so the username doesn't get corrupted. CVE-2019-3825 Closes https://gitlab.gnome.org/GNOME/gdm/issues/460
* manager,session: Add some debugging around starting reauthenticationIain Lane2019-02-061-6/+40
| | | | | | | | There's a bug right now dealing with timed login and reauthentication, but it's not clear what's going on by looking at the logs. This commit sprinkles some more logging throughout the code, to make the bug easier to track.
* manager: don't kill timed login session immediately after it startsRay Strode2019-02-061-1/+2
| | | | | | | | | At the moment GDM is misidentifying timed login sessions as if they are automatic login sessions. That leads to their displays getting killed sometimes shortly after log in. This commit corrects the check, so that timed login sessions aren't treated as autologin sessions.
* Use G_PARAM_STATIC_STRIGS on propertiesNiels De Graef2019-01-071-1/+1
| | | | This prevents strings from being unnecessarily copied.
* manager: do initial-setup post work in manager codeRay Strode2018-10-061-0/+132
| | | | | | | | | | | | Right now we do the initial-setup related post work when stopping the greeter, but the problem is we delay stopping the greeter now until after the user session is started. That post-work needs to be done before the user session is started. This commit moves the code to a more logical place.
* manager: correct display confusionRay Strode2018-10-011-2/+2
| | | | | | | | | commit c5c5bf1f reworked autologin and broke it. This commit addresses the breakage by accessing the proper display variable. Closes https://gitlab.gnome.org/GNOME/gdm/issues/426
* manager: don't run autologin display on tty1Ray Strode2018-09-251-3/+1
| | | | | | | | | | tty1 is really meant for the login screen. If a user autologins on it and we need a login screen later, then the login screen has to go in some auxiliary VT which isn't very nice. This commit changes autologin to not use the initial vt.
* manager: rework how autologin is figured outRay Strode2018-09-251-11/+35
| | | | | | | | | | | | At the moment we decide whether or not to perform autologin, by looking at if the display is the initial VT display and if autologin hasn't been started before. That isn't going to work in the future when autologin is started on a non-initial vt. This commit changes GDM to instead check if the seat is seat0, and if autologin hasn't run before, before deciding to do autologin.
* manager: fix build with --without-plymouthRay Strode2018-09-011-2/+2
| | | | | | | | | | | commit 80b46e2 accidentally put the `doing_initial_setup` boolean declaration inside a plymouth-enabled code path. That broke the build for non-plymouth users. This commit moves the declaration and the subsequent initialization to unconditionalized code.
* manager: don't kill initial-setup before starting user session on waylandRay Strode2018-08-311-5/+21
| | | | | | | | | | Right now we kill initial-setup before starting the session for the user initial-setup created. This is the right thing to do for Xorg, since Xorg can't be killed in the background, but it adds unncessary flicker for wayland. This commit checks if it's wayland and avoids killing it right away in that case.
* manager: start initial setup right awayRay Strode2018-08-311-66/+1
| | | | | | | | | | | | | | We no longer restart the greeter as soon as it dies, since we start the greeter on demand. This means, we no longer need to defer starting initial setup until after the greeter respawns. Furthermore, it doesn't work anymore since it relied on the respawn to trigger. This commit removes that code and scaffolding and just starts initial setup directly. https://gitlab.gnome.org/GNOME/gdm/issues/415
* manager: don't set ran_once after running initial-setupRay Strode2018-08-311-1/+3
| | | | | | | | | | | GdmManager tracks whether or not the user session has ran once, so it won't autologin a user again after logout. Unfortunately the initial-setup session was counting toward the ran_once count preventing initial-setup from logging the user in afterward. This commit prevents ran_once from getting set in that case.
* manager: better logind handlingRay Strode2018-08-311-3/+3
| | | | | | | | commit 9ee68d5c8 highlights we've incorrectly used ENOENT instead of ENXIO when checking for non-existing sessions/seats with logind. This commit mops up all the other cases.
* manager: plug leakRay Strode2018-08-311-1/+1
| | | | | We're quering the session-type of a display and not freeing the result.
* display-store: Pass the display object rather than the id in the removed signalChris Coulson2018-08-131-10/+9
| | | | | | | | | | | | | By the time GdmDisplayStore emits the "display-removed" signal, the display is no longer in the store and gdm_display_store_lookup will not work in signal handlers. Change the "display-removed" parameter from the display id to the GdmDisplay object, so that signal handers can perform any cleanup they need to do CVE-2018-14424 Closes: https://gitlab.gnome.org/GNOME/gdm/issues/401
* daemon: try harder to get to a login screen at logoutRay Strode2018-08-021-48/+0
| | | | | | | | | | | | | commit 22c332ba and some follow up commits try to ensure the user never stays on a blank VT by jumping to a login screen in the event they'd end up on one. Unfortunately, that part of the code can't start a login screen if there's not one running at all. This commit moves the code to GdmLocalDisplyFactory where the login screens are created, so users won't end up on a blank VT even if no login screen is yet running.
* common: dedupe activate_session_idRay Strode2018-08-021-33/+2
| | | | | | Right now there are three copies of activate_session_id. This commit consolidates the code to gdm-common.c
* common: dedupe gdm_get_login_window_session_idRay Strode2018-08-021-97/+2
| | | | | | | | Right now there are two slightly different cut-and-pastes of the function to get the session id of the login session in the code. This commit deduplicates them.
* manager: make get_login_window_session_id fail if no login screenRay Strode2018-08-021-2/+2
| | | | | | | Right now we oddly succeed from get_login_window_session_id if we can't find a login window. None of the caller expect that, so fail instead.
* manager: don't bail if session disappears out from under usRay Strode2018-06-221-0/+10
| | | | | | | | | | | | | | | It's entirely possible for a session returned by sd_seat_get_sessions to disappear immediately after the sd_seat_get_sessions call returns. This is especially likely at logout time where the session will briefly be in the "closing" state before getting reaped. If that happens when we're looking for a greeter session, we stop looking for a greeter session and bail out all confused. This commit fixes the confusion by gracefully handling the session disappearing by just proceeding to the next session in the list.
* manager: start login screen if old one is finishedRay Strode2018-06-221-1/+1
| | | | | | | | | | | | | | | | Since commit 22c332ba we try to start a login screen if we end up on an empty VT and there isn't one running. Unfortunately the check for "is on an empty VT" is a little busted. It counts the VT has non-empty if there's a display associated with it, even if that display is in the FINISHED state about to be reaped. That means, in some cases, we'll still leave the user on an empty VT with no login screen. This commit addresses the problem by explicitly checking for FINISHED displays, and proceeding even in their presense.
* manager: plug leak in maybe_activate_other_sessionRay Strode2018-06-221-1/+3
| | | | | | | The function asks logind what the currently active session is on the given seat. It then leaks the response. This commit plugs the leak.
* manager: gracefully handle the case of no session for login windowLubomir Rintel2018-06-221-2/+4
| | | | | | | | get_login_window_session_id() will return TRUE with session_id=NULL when there's no session. This restults in an assertion failure on constructing the o.fd.login1.Manager.ActivateSessionOnSeat() arguments: GLib: g_variant_new_string: assertion 'string != NULL' failed
* manager: avoid leaking session_idLubomir Rintel2018-06-221-0/+1
| | | | get_login_window_session_id() duplicates the session id.
* 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
View Lorry Controller Status