While the delay inhibitor is grabbed almost immediately, this can be
slow enough to not have happened immediately after the bus name has been
registered. Add a generous timeout to prevent issues.
If a print we have stored locally is not available in device anymore, we
need to cleanup the local database.
We do not get a proper DATA_NOT_FOUND error for most devices (indeed, at
this point no device does this properly). As such, do this when we see a
DATA_NOT_FOUND error and the first time that we get a verify-no-match
results on a device which is capable of listing all known prints.
Co-Authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
In case we got a data-not-found error, it means that the device has not
such prints stored, and thus the verification failed, and there's no
need to expose the internal reasons to fprintd clients.
For verify-match, the PAM module should simply drop off the bus. In
other cases it should correctly run VerifyStop and Release the device.
Verify this for verify-match and verify-no-match.
Before VerifyStart can be called again the current verify operation
needs to be completed. This requires waiting for VerifyStop to happen.
As such, remove the test, which is expected to fail randomly.
We just need large enough samples to tell them apart correctly. For this
a 128x128 area from the center of each image is sufficient.
This speeds up the test run considerably. Other ways of achieving this
could be to also lower the number of enroll steps for the image device.
While debugging the g-s-d testsuite a few more issues in the
OutputChecker code came up. Pull in these fixes ensuring that EOF and
the read side FD are handled correctly.
gnome-control-center expects to be able to re-enroll an existing print
when calling EnrollStart without deleting it first. As such, implicitly
delete the existing print rather than throwing an error.
Ideally, we'll change the API, but we need to give API users time to
adjust to the world.
This reverts commit ecf6b7c323.
The idea of the commit was to make device failures less fatal to the
system. Unfortunately, we can fail quickly in this case, and returning
PAM_AUTH_ERR means that the user might run into a retry limit due to
this.
Go back to reporting PAM_AUTHINFO_UNAVAIL, it appears as the lesser evil
right now. Ideally we want to a way to tell the upper stack to retry
authentication whenever there is a good opportunity, but to not consider
it as an authentication failure.
If the device supports listing prints, then we can do more targeted
deletes once the storage runs out. As such, do not try to clear the
storage on first enroll (therefore allowing dual boot setups to work to
a limited degree).
Clear the device storage before we enroll the first print. At that
point, we know that the storage should be completely empty and we have
no way of deleting "garbage" prints later if the device does not support
listing prints.
Always do an identify step before starting an enroll. If we find an
existing print, delete or throw an error depending on what is
appropriate.
Doing this ensures that we should not get duplicate prints system wide.
This means we will be able to identify the user that is trying to log
in. But more importantly, we need to do these checks for MoC devices,
which always run "identify" against all device stored prints rather than
the passed gallery.
During VerifyStart we may return early if there are no enrolled prints.
In such case we don't require the verification to be stopped if we're
using identification, but in the verification case we may leave the
device into the verification state.
So ensure we only set the device current state only when we're about to
start it.
Add tests ensuring those cases
The user may have some invalid prints saved (like the ones enrolled with
fprintd 1) in the storage, this lead to list such prints as enrolled but
they're actually not valid.
So load the prints to ensure that those are of the valid type instead of
just discovering them.
We may make just store.discover_prints to be aware of this, but this
would break some assumptions we do in tests, so better to go this way.
If something under the hood failed with a generic device error we'd just
mark the PAM module not available, this is probably too much as it may
just be due to a device temporary error.
So make it stop but allow the loading system to retry with it
Loading saved prints may lead to an error if they were stored long time
ago and so they're using a wrong format.
In such case we list the prints as available even though they are really
not, so the PAM module won't return PAM_AUTHINFO_UNAVAIL as in the
no-prints case but PAM_USER_UNKNOWN.
This will lead some auth systems (such as gdm) to keep retrying using
PAM fprintd module, even if it's not really available.
When saving the prints we use g_file_set_contents under the hood and in
case return its error code that is a positive value.
So in such case we don't fail if we have a write failure at the end of
the enrollment.
While we could ensure in file storage to always return a negative value,
it's always better to ensure that is has to be 0 when we didn't get an
error.
Add a test checking for this case.
