In case we get concurrent requests on EnrollStart/EnrollStop we'd just
continue with the operation, making the first processed request to start
the process and the second to hang (in code before the introduction of
stoppable_action_stop()) or to crash (in the current code).
So in such case we should always check that we're not handling already
the request, by checking priv->current_cancel_invocation value.
Add tests to verify the race.
Add a method to delete only a Fingerprint for a device, this is required
by they g-c-c UI design and at the same time it reflects the libfprint
API, where so far only a fingerprint at time can be deleted.
libfprint v1.90.4 introduced a new finger status API to expose to the UI
the finger status on sensor.
Add two new properties to the Device interface that represent the
possible values.
Add new tests.
The device DBus skeleton interface already implements caching for the
properties and can smartly handle their update sending (batched) dbus
events on changes.
Even if the default properties are only read only and we don't care, we
are going to introduce properties that will change values, and so having
the skeleton to handle this for us is quite convenient.
Given that we don't really need to override those properties, we can
just set them at start and leave the skeleton cache to handle the rest.
In case we'd ever need to override them, however the skeleton also
provides a way to override all the properties and to get a reference of
the number of properties it defines, ensuring to keep the order they are
defined.
This would allow us to get back the parent's properties IDs and to use
this to implement ours properties getters/setters using the parent one
as fallback.
It makes sense to allow interrupting fingerprint authentication, but PAM
does not provide a way to define an interruptable operation.
We can work around this somewhat though by at least reacting to SIGINT
in an interactive terminal. Obviously, we shouldn't override the signal
handler, because that would be too intrusive. But creating a signalfd is
easy enough and doesn't affect the rest of the process state as much.
This makes garbage collection a bit more predictable overall. Note that
we'll first delete prints that we do not know the age of.
If we cannot sort them by age, then randomize the order so that we don't
end up deleting in the order that the device returned the prints.
The stoppable actions (Verify/Enroll) have the same logic during
completion. Create a common function to share this logic instead of
copying it in each of the handlers.
Fixes: #97
When multiple devices are available PAM module will just pick the first
one, even if it has not enrolled fingers.
Since this can't be user configured (yet) we can be a bit smarter and
select the device that has more fingerprints configured for the user.
In the garbage collection code we always ended up to load the first
enrolled print, and this may lead to removing from device storage prints
that are actually in use.
We have a condition where a client vanishing instead of cleaning up the
operation using VerifyStop would cause fprintd to hang. This only
happens if the underlying enroll/verify/identify operation has already
finished when the client vanishes.
Fix this by correctly interpreting current_cancellable as a flag for
these operations.
Fixes: #97
This is useful in the functions where we have to unset the device's
current action but we may use early-return to handle multiple conditions
such as in open, close and delete functions.
The latest also currently is a bit buggy as it won't reset the state on
some failures.
In the usual test we cancel the operation immediately by calling
VerifyStop. This (often) tests the case where we don't end up restarting
the Verify operation internally.
We can easily force fprintd to have restarted already internally, so add
a test that does so by sleeping a bit. This should give us a slightly
higher branch coverage in the verify_cb/identify_cb tests.
