Passing parameters to cryptsetup when unlocking volume

[somewhere-or-other]

Is there already a mechanism when unlocking a clevis/luks volume, to pass arbitrary parameters to the underlying cryptsetup? My integration work with pacemaker, may require being able to pass along a --disable-locks to the final cryptsetup open. If there's a way to do that already, it's not obvious to me.

To be clear, I'm fine doing the work of writing and testing patches. I just didn't know if there was already a way to do it, that I was missing.

Assuming that I need to patch clevis-luks-unlock, is it preferable to have explicit parameters for the ones we might want to pass along (eg --disable-locks), or would a more generic one that passes everything (eg. based on $@ in bash), be preferable?

[sarroutbi]

Hello. I don't think there is such an option. In the end, the only available options for "clevis luks unlock" are:

OPTIONS
• -d DEV : The LUKS device to unlock
• -n NAME : The name to give the unlocked device node
• -t SLT : Test the passphrase for the given slot without unlocking the device

When inspecting the code of the unlock command, no additional options exist:

$ grep cryptsetup /usr/bin/clevis-luks-unlock | grep open
echo -n "${pt}" | cryptsetup open -d- "${DEV}" "${NAME}"

Feel free to open a new enhancement issue for this option, and, if possible, submit a patch. Regarding the options, I consider cryptsetup has too many options for clevis to add a particular one for this, so, from my perspective, I guess it is better to add a generic option to clevis-luks-unlock to attach to "cryptsetup open", although it is more error prone.

@sergio-correia , what's your view on this?

[somewhere-or-other]

Pull Request submitted. This is just a quick, minimally-tested version, so feel free to give feedback there, if I've made any egregious errors, etc.

[somewhere-or-other]

Because I've got the pull request in now, I'm inclined to close this, and let all discussion happen over there. That way there's only one discussion thread to worry about, instead of two.