| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
session-worker: Use clearer message errors on max retries and using auth method infos
See merge request GNOME/gdm!122
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we use a gdm well known authentication method, we can be a bit more
clear when showing the error to the user on what explicitly failed.
So add functions to get the friendly error message per authentication
method.
To make them clearer for translators, I've added some repeated strings
as generating them could lead to misleading results in some locales.
|
| |/
|
|
|
|
| |
Some PAM modules we use by default (such as the fingerprint one)
supports this, so in case we receive a max-retries error we should
inform the user with some clearer message.
|
| |\
| |
| |
| |
| | |
session-worker: Don't switch back VTs until session is fully exited
See merge request GNOME/gdm!123
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a race condition on shutdown where the session worker is
switching VTs back to the initial VT at the same time as the session
exit is being processed.
This means that manager may try to start a login screen (because of
the VT switch) when autologin is enabled when there shouldn't be a
login screen.
This commit makes sure both the PostSession script, and session-exited
signal emission are complete before initiating the VT switch back
to the initial VT.
https://gitlab.gnome.org/GNOME/gdm/-/issues/660
|
| |\
| |
| |
| |
| | |
more gdm client fixes
See merge request GNOME/gdm!121
|
| | |
| |
| |
| | |
It's been out of date for a while.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The unlock screen may have user verifier extensions too, so we
need to track the reauth user verifier, too.
This API is clearly less than optimal, but fixing it is a task for
another day.
|
| | |
| |
| |
| | |
This makes the code much tidier.
|
| |/
|
|
|
|
|
|
|
|
| |
Since commit 2615fb4ffe05b2640c15f4a9706796fe3b1376a9 user verifier
extensions are stored as user data on the user verifier object.
Unfortunately that commit, mixed up where the user verifier object
was in place.
This commit fixes that.
|
| | |
|
| |\
| |
| |
| |
| | |
build: add meson_post_install.py properly
See merge request GNOME/gdm!112
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
display: Don't try to start gnome-initial setup on users check failure
Closes #642
See merge request GNOME/gdm!117
|
| | |
| |
| |
| | |
It will make things just cleaner
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Given not having users may make GDM to launch initial setup, that
allows to create new users (potentially with sudo capabilities), it's
better to make look_for_existing_users() to return its status and only
if it didn't fail continue the gdm execution.
GHSL-2020-202
CVE-2020-16125
Fixes #642
|
| |\
| |
| |
| |
| | |
libgdm proxy leaks
See merge request GNOME/gdm!120
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
GdmClient fails to free the hash table associated with user
verifier extensions when the client is done with the user verifier.
This commit ties the user verifier extensions to the user verifier
instance associated with it, instead of storing the extensions
directly in the client struct.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a race condition in the client connection code at the moment,
where a user verifier could be waiting for its connection when the login
screen asks for a greeter synchronously. The greeter will then end up
with a different connection that the user verifier which breaks
expectations.
This commit just makes the connection fetching code synchronous for now
to side step the problem.
|
| |/
|
|
|
|
|
|
| |
There are are few places in the code where the client object is
retrieved via g_async_result_get_source_object. Those calls
return a fresh reference that is never unreferenced later.
This commit plugs those leaks by using g_autoptr's
|
| |\
| |
| |
| |
| | |
utils: add enabling Wayland feature into gdm-disable-wayland
See merge request GNOME/gdm!115
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can disable Wayland in runtime by invoking gdm-disable-wayland.
However, we may also want to enable Wayland in runtime for some
reasons. This idea is extended to modify more options/configurations in
runtime.
This commit renames gdm-disable-wayland to gdm-runtime-config and
unlocks the feature to modify more gdm configurations in runtime.
The new command format will be:
gdm-runtime-config set <group> <key> <value>
The configurable items refer to gdm.schemas. "<group>/<key>" combination
is the key in gdm.schemas.
For example, the original "gdm-disable-wayland" is replaced by
"gdm-runtime-config set daemon WaylandEnable false".
Link: https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/115#note_944907
|
