| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
The display object stores its associated user session with it
as object data. It never clears this session from its object
data when its done with it however, leading to the session leaking.
This commit plugs the leak and an associated file descriptor leak
at logout.
|
|
|
|
|
|
|
|
| |
The create_user_session_for_display function returns a new reference
to the GdmSession object it creates. The callers don't expect this,
and most of the callers don't even look at the return value at all.
This commit makes it return void instead.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When GDM is configured as a standalone XDMCP server, the manager quits
Plymouth by running 'plymouth quit --retain-splash'. This is not ideal
because there is no transition to a local X server. The terminal can be
then left from the Plymouth run in the graphics mode with no getty
prompt and also disallowing switching to another VT. The patch fixes the
problem by instead running 'plymouth quit' which always switches the
terminal to the text mode.
https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/101
|
|
|
|
|
|
|
|
|
|
| |
The get_display_and_details_for_bus_sender function does not return a
proper error value. Due to this, it makes sense to always write the out
parameters (though, I expect we have still more that we might need to
write).
This is just slightly safer, but the function probably isn't great as
is.
|
|
|
|
|
|
|
|
|
|
|
| |
Some people insist on running sessions in ways where we cannot detect
them properly. In that case, we shouldn't find a display, but the
variable was not initialized and we could end up accessing random memory
resulting in a crash.
Fix it by adding the missing initializer.
Closes: #555
|
|
|
|
|
|
|
|
|
| |
The login screen for both Xorg and wayland sessions is now silently
killed in the background post login.
We still kill initial-setup for Xorg sessions up front, though.
This commit fixes that.
|
|
|
|
| |
distributions' directory architecture.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, GDM may be running multiple greeters, and each greeter is
currently using the same user. So while in a lot of setups each user
should only have one graphical session and also only one DBus session
bus, this is not true for the gdm greeter.
Lacking another solution (e.g. separate users), we need to be able to
correctly lookup the session information for all greeter instances. We
can do so by using sd_pid_get_session and using this information is safe
if it does return something.
See: #526
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial setup home dir should be owned by the initial user created
during the gnome-initial-setup to be able to copy all config to the new
user with the gnome-initial-setup-copy-worker.
The owner of this homedir is been changed if the session is different
from GDM_SESSION_DISPLAY_MODE_REUSE_VT but in this case the manager is
not calling this function.
This patch moves the call to this function outside the if-else to fix
the gnome-initial-setup process in the first case.
https://gitlab.gnome.org/GNOME/gdm/merge_requests/70
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Window managers can use this to register with GDM when they've finished
starting up and started displaying.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This prevents strings from being unnecessarily copied.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
We're quering the session-type of a display and not freeing
the result.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Right now there are three copies of activate_session_id.
This commit consolidates the code to gdm-common.c
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
The function asks logind what the currently active session is on the
given seat. It then leaks the response.
This commit plugs the leak.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
get_login_window_session_id() duplicates the session id.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This function iterates through a list so calling the action find
is more appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=784555
|