be8a1dc...
by
Gustavo Noronha Silva <email address hidden>
calendar-server: Fix double-free detection abort
app_notify_events_added uses an intermediate builder to construct an
array that is then added to the main variant using g_variant_builder_add
which should clear the intermediate, but doesn't due to the way it is
passed: by value, rather than as a pointer.
This was debugged with the help of Eduardo Habkost, who believes it
works on x86 due to big structs being passed as pointers.
gdm: Don't try to retry authenticating when the service is unavailable
In the case a service is not available (as it can be in the fingereprint
case when a supported reader is available but has not enrolled prints)
we were trying indefinitely to restart it.
However, in such cases the PAM services are expected to return a
PAM_AUTHINFO_UNAVAIL and gdm to handle it, emitting service-unavailable
signal.
So connect to ::service-unavailable and keep track of the unavailable
services so that we can avoid retrying with them.
In case such service is not the foreground one, we can just silently
ignore the error, without bothering failing the whole verification.
In case we got a valid error message on service-unavailable, we also
show it, this is normally not happening unless GDM isn't redirecting
here other kind of problems (such as MAXTRIES) which are supposed to
stop the authentication stopping any further retry.
When the login/lock screen is shown the error messages for background
services are always ignored.
However, in case the service is the fingerprint authentication method
we still want to be able to show error messages to inform the user
about what failed, and eventually that the max retries (that may be
different from the login screen configuration) has been reached.
This handles partially the design issue [1] related to the login/lock
screen fingerprint authentication.
Eventually we want to use pam extensions to use clearer and parse-able
messages, however in the case of the fingerprint service we can be sure
that the fprint PAM module will only send errors on auth failures.
ShellUserVerifier: Add method to check if the service name is fingerprint
We have multiple places where we check if we're handling a fingerprint
event, so let's add a common public function so that it can be used also
by the authPrompt.
gdm: Ensure we cancel all the previously running services on auth retry
When retrying the authentication we should make sure that all the
previously initiated services are stopped in order to begin a new
authentication session with all the configured services.
Unfortunately at the current state we only dispose the currently used
user verifier, but we don't make it to stop all the relative gdm workers
and then they'll stay around potentially blocking any further usage of
them (as it happens with the fingerprint one, that has unique access to
the device).
So, cancel the currently running authentication before starting a new
one if we're explicitly retrying.
gdm: Do not fail the whole authentication if a background service failed
In case a background service such as the fingerprint authentication
fails to start we'd just mark the whole authentication process as
failed.
Currently this may happen by just putting a wrong password when an user
has some fingerprints enrolled, the fingerprint gdm authentication
worker may take some time to restart leading to a failure and this is
currently also making the password authentication to fail:
JS ERROR: Failed to start gdm-fingerprint for u: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.Spawn.Failed:
Could not create authentication helper process _promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:435:45
### Promise created here: ### _startService@resource:///org/gnome/shell/gdm/util.js:470:42 _beginVerification@resource:///org/gnome/shell/gdm/util.js:495:18 _getUserVerifier@resource:///org/gnome/shell/gdm/util.js:405:14 async*_openReauthenticationChannel@resource:///org/gnome/shell/gdm/util.js:378:22 async*begin@resource:///org/gnome/shell/gdm/util.js:194:18 _retry@resource:///org/gnome/shell/gdm/util.js:561:14 _verificationFailed/signalId<@resource:///org/gnome/shell/gdm/util.js:584:30 _emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47 finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:268:14 _queueMessageTimeout@resource:///org/gnome/shell/gdm/util.js:273:18 _queueMessageTimeout/this._messageQueueTimeoutId<@resource:///org/gnome/shell/gdm/util.js:288:65
Given that background services are ignored even for queries or any kind
of message, we should not fail the authentication request unless the
default service fails.
gdm: Don't try answering query if the user verifier has been deleted
Answering a query may be delayed to the moment in which we've not any
more messages in the queue, however this case can also happen just after
we've cleared the UserVerifier and in such case we'd have nothing to
answer, but we currently throw an error:
JS ERROR: Exception in callback for signal: no-more-messages:
TypeError: this._userVerifier is null
answerQuery/signalId<@resource:///org/gnome/shell/gdm/util.js:249:17
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:266:14
_clearMessageQueue@resource:///org/gnome/shell/gdm/util.js:301:14
clear@resource:///org/gnome/shell/gdm/util.js:223:14
cancel@resource:///org/gnome/shell/gdm/util.js:205:18
reset@resource:///org/gnome/shell/gdm/authPrompt.js:482:32
cancel@resource:///org/gnome/shell/gdm/authPrompt.js:569:14
vfunc_key_press_event@resource:///org/gnome/shell/gdm/authPrompt.js:128
So handle this case more gracefully keeping track of the current
cancellable and checking whether it is still valid before trying to answer
a query or do a delayed action.
authPrompt: Don't begin a new authentication session on lockscreen cancel event
When a cancel event in the user lockscreen happens we first emit a reset
signal and immediately a cancelled one.
This lead to start a new gdm worker for each enabled authentication
method and then immediately to stop it.
As per the previous commit, we don't have anymore dangling gdm workers
around, but still we should not even start a new one in such case.
So, when the user explicitly cancelled the authentication session, first
emit a cancelled event and only emit a reset event with a begin request
if we are outside the lockscreen.
