I see in the source code of libpam-mount (loop.c):

static bool ehd_load_2(struct ehdmount_ctl *ctl)
{
       int ret;
       bool is_luks = false;
       const char *start_args[11];
       struct HXproc proc;

       ret = ehd_is_luks(ctl->lower_device, true);
       if (ret >= 0) {
               int argk = 0;

               is_luks = ret == 1;
               start_args[argk++] = "cryptsetup";
               if (ctl->readonly)
                       start_args[argk++] = "--readonly";
               if (ctl->cipher != NULL) {
                       start_args[argk++] = "-c";
                       start_args[argk++] = ctl->cipher;
               }
               if (is_luks) {
                       start_args[argk++] = "luksOpen";
                       start_args[argk++] = ctl->lower_device;
                       start_args[argk++] = ctl->crypto_name;
               } else {
                       start_args[argk++] = "--key-file=-";
                       start_args[argk++] = "-h";
                       start_args[argk++] = ctl->hash;
                       start_args[argk++] = "create";
                       start_args[argk++] = ctl->crypto_name;
                       start_args[argk++] = ctl->lower_device;
               }

It can't have a keyfile if it is a luks volume.

I then noticed the obscure distinction in the documentation of mount.crypt between a 'crypto' (=dm-crypt?) and a luks volume:
      keyfile
The path to the key file. This option is mandatory for "normal" crypto volumes and should not be used for LUKS volumes.

So, the conclusion is that mount.crypt which can successfully mount a luks volume with a passphrase, cannot mount a luks volume with a keyfile. Is that a feature? I think it is a bug...

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to