| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
If a client has a reference to a session that starts running,
refuse to allow further operations on the session.
CVE-2019-3825
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Launch systemd service with KeyringMode=shared
See merge request GNOME/gdm!53
|
| |/
|
|
|
|
|
| |
This allows gdm to pass the LUKS password through to PAM.
The login keyring will now be unlocked automatically if autologin is
enabled!
|
| |
|
| |
This reverts commit 762b312bb98d31bd036fbcc8d61e53d5b1298d65
|
| |
|
|
|
| |
This allows gdm to pass the LUKS password through to PAM.
The login keyring will now be unlocked automatically if autologin is enabled!
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
manager: do initial-setup post work in manager code
See merge request GNOME/gdm!50
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
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 confusion
Closes #426
See merge request GNOME/gdm!49
|
| |/
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Wip/gdm vt switch fixes
See merge request GNOME/gdm!48
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We may end up re-using a display in waiting-to-finish state before it gets
finished in this case reset its state to managed to avoid it getting
finished while it is being used.
Closes https://gitlab.gnome.org/GNOME/gdm/merge_requests/45
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We avoid changing to the login screen vt if we're already on it,
but the call is racy since we react to vt changes concurrently
with logind (who we query for the active vt).
This check drops the active vt check since it's pointless and
getting in the way.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The initial VT is in use check in on_vt_changed() is racy, when switching
to VT1 from an active session, on_vt_changed() may run before logind has
processed the VT change and then sd_seat_get_active() will return the
active session which we are switching away from. This results in the greeter
not being started on VT1.
On my system gdm reliably wins the race resulting in not getting a greeter
when manually switching from an active session to VT1.
gdm already starts the greeter unconditionally from
gdm_local_display_factory_sync_seats() on both startup and when an user
session exits. gdm also starts it unconditionally when selecting
"Switch user" from an user session.
Now autologin sessions avoid the initial VT as well.
So we now can assume that the initial VT is free for the login screen's
use. And create_display already checks for and re-uses
an existing greeter, so we can safely remove the racy check.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
| |
We automatically kill the login screen when switching VTs away
from it, but we should never kill the initial-setup screen in
that situation.
This commit adds a check to prevent that from happening.
|
| |\
| |
| |
| |
| | |
daemon: Move the waiting for the session to have taken over the fb to gdm-local-display-factory
See merge request GNOME/gdm!47
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gdm-local-display-factory
Commit 708618746683 ("gdm-wayland-session,gdm-x-session: register after
delay") delayed displays changing their status from PREPARED to MANAGED
so that their status would not change until the session has had a change
to install its own framebuffer and tell the GPU to scanout this new fb.
Commit 74ee77717df7 ("local-display-factory: defer killing greeter until
new session registers") uses this to avoid a flicker when transitioning
from the greeter to the user-session by deferring the stopping of the
greeter-session until the new display moves to the MANAGED state.
But this only works when transitioning to a new user-session, when moving
to an existing user-session (fast user switching) the display already
is in MANAGED state and instead of deferring the stopping of the greeter
commit 74ee77717df7 causes us to now never stop the greeter-session.
This commit fixes this by starting a timeout when switching away from
the initial-vt and letting that timeout stop the greeter-session.
This commit removes the finish_waiting_displays_on_seat() call when the
display's status changes to MANAGED, so that we still only have one code
path stopping the greeter and not two.
This means we also no longer need to delay registering the display. So this
commit removes the code adding the delay (reverts commit 74ee77717df7).
Note this commit uses a delay of 10 seconds, rather then 2 seconds. The
transition to a new user-session takes about 8 seconds on my budget
Apollo Lake based laptop (with SSD).
Note this all really is a workaround, the proper solution for this would
be able to tell the kernel to keep the greeter framebuffer around until
a new framebuffer is installed. There is a patch to add a new unref_fb
ioctl for this: https://www.spinics.net/lists/dri-devel/msg140912.html .
We need to get this patch upstream and teach mutter to use it.
|
| |\
| |
| |
| |
| | |
data: disable wayland for proprietary nvidia machines
See merge request GNOME/gdm!46
|
| |/
|
|
|
|
|
|
|
| |
At the moment GLX applications don't work well when the
proprietary nvidia driver is used with a wayland session.
For now, disable wayland on that hardware, and users who
want to opt in can just edit the udev rule.
(or add their own that overrides it)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Different distributions place udev rules in
different locations (depending on whether or
not /usr is a symlink to /)
That means the location needs to be configurable.
This commit adds a new ./configure argument,
--with-udevdir that allows distributions to specify
where udev looks for its data files.
By default it pulls the answer from pkg-config.
This commit also fixes `make distcheck` when run
by an unprivileged user by disabling udev rule
installation entirely during distcheck.
Small changes by Ray Strode.
Closes https://gitlab.gnome.org/GNOME/gdm/merge_requests/44
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Build fixes eek
Closes #416
See merge request GNOME/gdm!43
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
commit cf8d918f added a call to `lookup_by_session` which
was previously only defined when built GDM was built with
`--enable-user-disable-server`.
That causes the build to fail with `--disable-user-display-server`.
This commit fixes the build by moving `lookup_by_session` out
of conditionalized code.
Closes https://gitlab.gnome.org/GNOME/gdm/issues/416
|
| |/
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Wip/initial setup flicker fix
See merge request GNOME/gdm!42
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
|
| |
While we've been using wayland by default for the login screen
for a long time, and for the user session for somewhat less time,
we never switched initial setup over.
It's still using X11 for no good reason.
This commit changes initial-setup to use wayland by default like
everything else.
|
| |\
| |
| |
| |
| |
| |
| | |
Wip/flicker fix
Closes #413
See merge request GNOME/gdm!41
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
At the moment we kill the greeter the second the VT change to the new
session happens.
That can cause flicker if the new session doesn't take over the display
quickly enough.
This commit defers killing the greeter until the new display registers.
Closes https://gitlab.gnome.org/GNOME/gdm/issues/413
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now gdm-x-session registers with GDM as soon as the
X server is started, and gdm-wayland-session registers as
soon as the session is started.
Ideally registration wouldn't happen until the session
says things started successfully.
This commit inches us toward that ideal but adding a little
timeout before proceeding with registration.
A future commit will add a new xsession file key to allow
us to know whether or not the session manager of the session
supports doing registration.
|
| |\
| |
| |
| |
| | |
Wip/fix initial setup
See merge request GNOME/gdm!40
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
