Right now we always get G_IO_ERROR_FAILED when the passphrase check fails when unlocking an encrypted volume. It would be nice to detect such a case without having to guess it from the error string returned by cryptosetup.
Hi, When I tested mounting a LUKS encrypted drive and run this test program, the output which I got is: ----------------------------------------------------------------------------------- $ ./test FOUND block_devices/sdb1 Error unlocking /dev/sdb1: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/sdb1: Command-line `cryptsetup luksOpen "/dev/sdb1" "luks-73e34a00-702c-4932-9d5d-be5941e86090" ' exited with non-zero exit status 2: No Key available for this passphrase. , 66, 0 G_IO_ERROR=405, G_IO_ERROR_FAILED=0 UDISKS_ERROR=66, UDISKS_ERROR_FAILED=0 ----------------------------------------------------------------------------------- As you can here, the error which we are getting is not the same as the bug report. But it's not surprising as the bug is quite old and someone maybe has corrected it without knowing. So, I would like you to go through the testcase which I'm attaching here and review it.
Created attachment 114880 [details] [review] Test case proving that the bug is not valid anymore. Attaching the compressed version of the test case which consists of the "Makefile" and "test.c" files.
Created attachment 114881 [details] [review] Test case proving that the bug is not valid anymore. Just attaching the test.c (testcase) here.
Cosimo, can you please be more specific where you get that error message/code (GUI/some API call, which and where?) and what you expect instead? Anup, thanks for the demo script!
(In reply to Martin Pitt from comment #4) > Cosimo, can you please be more specific where you get that error > message/code (GUI/some API call, which and where?) and what you expect > instead? Martin, I don't remember exactly the issue now (been a while), but I think that when I filed this issue, failing an unlock passphrase was returning a generic "failed" message (in e.g. Nautilus) since the GIO return code wasn't specific enough, and after checking with David it was because parsing that kind of error out of cryptsetup was not easy. If that's not the case anymore, feel free to close this issue!
GVfsUDisks2VolumeMonitor mounting and unlocking luks encrypted devices. However we don't know from the error code if passphrase is invalid if udisks_encrypted_call_unlock() failed, or if something else happened. It fails with following error if the provided passphrase is invalid: - Error unlocking /dev/sdb1: Command-line `cryptsetup luksOpen "/dev/sdb1" "luks-90c34690-5f6f-4adf-9333-7651ccfa0a29" ' exited with non-zero exit status 2: No key available with this passphrase. Following errors comes from udisks_encrypted_call_unlock() if device is removed in the meantime: udisks_encrypted_call_unlock() can fail e.g. with following errors (): - Error unlocking /dev/sdb1: Command-line `cryptsetup luksOpen "/dev/sdb1" "luks-90c34690-5f6f-4adf-9333-7651ccfa0a29" ' exited with non-zero exit status 4: Device /dev/sdb1 doesn't exist or access denied. - Error unlocking /dev/sdb1: Command-line `cryptsetup luksOpen "/dev/sdb1" "luks-90c34690-5f6f-4adf-9333-7651ccfa0a29" ' exited with non-zero exit status 1: IO error while decrypting keyslot. Problem is that all those errors have same domain and code, i.e. UDISKS_ERROR and UDISKS_ERROR_FAILED, and only way how to distinguish them is string comparing. Would be best if there will be some specific error code e.g. UDISKS_ERROR_PASSPHRASE_INVALID for the case when passphrase is invalid... So we need this in gvfs and the attached test case is irrelevant... Cosimo, I hope it is what you meant.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.