Re: Bug: luksClose search LUKS header but it is detached

Hi Milan,

I appreciate your quick response.

Here is my reply:

> No, this is expected. But for close (deactivation) it proceeds even
> if it does not find the detached header.

Why would cryptsetup seek the detached header in the device?
Wouldn't it be better for cryptsetup to use the '--header' flag?

> The reason is that even close need some information from the header
> (for example UUID).

Doesn't the linux kernel store this kind of information?

> Is there any functional problem with this or it just looks strange?

There isn't any issue.
I just noticed an unexpected behavior and thought that I should report about it.

Best regards,
David.


On Wed, Aug 10, 2022 at 9:58 AM Milan Broz <[email protected]> wrote:
>
> On 09/08/2022 23:53, [email protected] wrote:
> > Hi all,
> >
> > I noticed that cryptsetup LUKS extensions is searching for a LUKS
> > header in the device.
> > This is expected when the LUKS header should be in the device.
> > But I used a detached LUKS header, so I wasn't expecting to see
> > cryptsetup searching for the LUKS header in the device.
> >
> > You can see that in the log file "log.txt" - in the URL:
> > https://drive.google.com/file/d/1DcrpklgE75oE5znAxHAlp9CPikkYbVq1/view?usp=sharing
> >
> > You may notice that I used a "--header" flag, but I also tried without
> > it - still, cryptsetup behaved the same.
> >
> > The incriminating lines from the attached log are as follows:
>
> ...
> > Do you consider it to be a bug?
>
> Hi,
>
> No, this is expected. But for close (deactivation) it proceeds even
> if it does not find the detached header.
>
> The reason is that even close need some information from the header
> (for example UUID).
>
> Is there any functional problem with this or it just looks strange?
>
> If it is problem, you can always use low-level access through
> "dmsetup remove <device>" here, but it can keeps some underlying device
> active (for LUKS2 this is used only for integrity protected devices).
>
> Milan
>
>