Ah. Thanks for the detailed response.
Yes, I know, ancient. Unfortunately I have to support an older system here for a few more months.
On Thu, Sep 20, 2018 at 11:57 PM, Milan Broz <gmazyland@xxxxxxxxx> wrote:
It is not so easy as you think. The keyslot must be decrypted and for that it need kernel crypto.On 21/09/18 00:57, Frank Cusack wrote:
> cryptsetup 1.6.1
>
> cryptsetup --test-passphrase luksOpen /path/to/image
>
> (note: /path/to/image is not a device path) complains
>
> Cannot use a loopback device, running as non-root user.
>
> Given that the header can be dumped without being root, it seems true that one should be able to test the passphrase without being root, as long as you can access the header/image.
>
> I can see in lib/device_utils.c`device_internal_prepare that indeed, cryptsetup makes this check proactively rather than just failing somewhere else. In the case of --test-passphrase, is this really needed?
>
> I don't think that is the code path for --test-passphrase though, since --test-passphrase doesn't require a device path whereas the referenced code does seem to require it. I didn't search exhaustively for that error message, just stopped at the first place where it seems superfluous. Couldn't a process have a mount capability without being uid 0?
If there kernel userspace crypto API available, cryptsetup does not need loopback files, nor access to device-mapper ioctl (both requires root)
and --test-passphrase works with normal user account.
Just please use recent crypsetup (version 1.6.1 is 5 years old!)
But if the the crypto API is not available - basically af_alg and other kernel modules - we have to use fallback
through dm-crypt for keyslot decryption and that require loop device mapping.
Boot is root (CAP_SYSADMIN) only. This is limitation outside of cryptsetup.
Milan
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
