When starting an enroll when verification is in progress (and vice-versa) we
emit an AlreadyInUse error, however when calling VerifyStop() during an
enrollment (and vice-versa) we just return a NoActionInProgress error, which
is not the case.
So let's be consistent and change the error type.
If a device is currently verifying, identifying or enrolling we may want the
user to stop the operation before we actually release the device.
Otherwise we may end-up in trying to close (failing) the internal device,
while fprintd is still considering the device active, causing a dead-lock
(the device can't be released, but neither claimed again or stop the current
action).
In fact calling Claim() -> EnrollStart() -> Release(), we would fail with
the error
net.reactivated.Fprint.Error.Internal:
Release failed with error: The device is still busy with another
operation, please try again later. (36)"
However, if we try to call VerifyStop, after this error, we'd fail because
for the fprintd logic, the device is not claimed anymore, but actually
closed, and we'd need to claim it again, but... That would still cause an
internal error.
To avoid this, in case Relase() is called cancel the ongoing operation,
and wait until it's done before completing the release call.
When starting an identify operation we allocate a gallery of prints from the
gallery, although if we match one of them we get that back in the finish
callback but with a further reference added.
So, in order to clean it up, use an auto-pointer or we'd end up in leaking
it, and the address sanitizer was catching this in our tests already:
Indirect leak of 12020 byte(s) in 5 object(s) allocated from:
#0 0x7fe8bc638ce6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
#1 0x7fe8bc37ffd0 in g_malloc0 ../../glib/glib/gmem.c:132
#2 0x55d100635c01 in load_from_file ../src/file_storage.c:159
#3 0x55d100635c01 in file_storage_print_data_load ../src/file_storage.c:182
#4 0x55d10063e950 in fprint_device_verify_start ../src/device.c:882
#5 0x55d10064036b in dbus_glib_marshal_fprint_device_VOID__STRING_POINTER src/device-dbus-glue.h:96
#6 0x7fe8bc50f6f5 (/usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2+0xd6f5)
When using the delete method we check if the device was claimed, if this
fails because the device is already in use we return an error, but we don't
free the user.
While this could be fixed by just a further g_free call, let's just remove
remove the other manual free calls, and use an auto-pointer instead for this
function.
During delete enrolled fingers2 call, if the check-claimed control fails, we
would return the error without freeing it.
While this could be fixed by just a further g_error_free call, let's just
remove the other manual free call, and use an auto-pointer instead for this
function.
During delete enrolled fingers call, if the check-claimed control fails, and
we get an error different from FPRINT_ERROR_CLAIM_DEVICE, we would return
the error without freeing it.
While this could be fixed by just a further g_error_free call, let's just
remove all the manual free calls, and use an auto-pointer instead for this
function.
With the stronger warnings enabled when building with meson, we get a
warning for all the fingers definitions:
../src/device.c:38:24: warning: initialization discards ‘const’ qualifier
from pointer target type [-Wdiscarded-qualifiers]
38 | [FP_FINGER_UNKNOWN] = "unknown",
As the `fingers` array name was shadowed in another file:
../src/device.c:1000:11: warning: declaration of ‘fingers’ shadows a
global declaration [-Wshadow]
1000 | GSList *fingers, *finger;
Use the device session data to store all the informations we care about
while a device is claimed, and make its cleanup easier.
Keep just one instance of the current context, given we use it only during
claim and release, and those are mutually exclusive operations.
Allocate SessionData using g_malloc(). There are no benefits to using
GSlice for a seldom used structure. This also allows use to use
g_clear_pointer() to free the struct.
This API was added to libfprint to allow drivers to report the match
result early before the operation has been completed. No driver makes
use of this facility yet and instead drivers try to finish the
operation early for quick result reporting. This primarily means not
waiting for finger removal.
Once drivers are updated, fprintd reactivity will regress unless the
early match callback is implemented as they would only get an operation
finished callback when the whole of the operation was finished,
including finger removal and finishing up USB communications.
See: https://gitlab.freedesktop.org/libfprint/fprintd/issues/35
Some devices require storing the print on the device, to support this,
try deleting prints from the device before deleting them from local
storage.
To handle these devices, add a new API that requires the device to be
claimed rather than allowing deletion without claiming the device first.
Also add appropriate fallbacks so that the old API will continue to
work, but warn about its use.
The new libfprint version has support for devices that store data on the
sensor. In that case, the on-sensor storage might fill up when the user
tries to enroll a new print.
The strategy introduced here to handle this is to try and delete prints
from the device that we do not know about (assuming, it is e.g. from an
old installation and unusable).
It can also happen that we are not able to garbage collect old prints.
If that happens, a new error code "enroll-data-full" will be returned
signalling the situation to the enrolling application.
fprintd's API docs say that "retry" errors for verification
"the verification is still ongoing" and that "[the] user should retry
scanning their finger.
Unfortunately, retry errors are fatal in libfprint. Make fprintd restart
operations when "retry" is the error for either identification or
verification purposes.
We need to also make sure that a "*Stop" D-Bus call will return as
normal if called while we're stopping a verification or identification
in order to restart it.
Closes: #22
Fix a possible crash when an fprintd client disappears. If the client
requested for the device to be released, then, without waiting for the
reply of that release, disappeared from the bus, we would try to close
it a second time, accessing a function pointer that didn't exist
anymore.
See https://bugzilla.redhat.com/show_bug.cgi?id=1515720
Pretty hacky way to detect whether the device we're handling has
been disconnected during a verify or enrollment. This should allow
us to avoid users having to wait when somebody pulls the plug.
- Use D-Bus native properties instead of a GetProperties call.
- Fix a number of front-ends by registering the right signals and
marshallers following the "done" signal argument addition
- Fix VerifyStart call in the pam module
