[dm-crypt] Unexpected behavior in cryptsetup-1.5.1

[dm-crypt] Unexpected behavior in cryptsetup-1.5.1

[jason_daly]

Hello,

I recently upgraded to cryptsetup-1.5.1 and I ran into some unexpected
behavior with this new version.

The issue happens when creating LUKS-formatted container files, as follows:
=====================================================================
dd if=/dev/urandom of=container bs=1M count=8
cryptsetup -v luksFormat container

WARNING!
========
This will overwrite data on container irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Cannot wipe header on device container.
Command failed with code 22: Cannot wipe header on device container.
=====================================================================
To get it to work, I now have to set up a loopback device:

losetup /dev/loop7 container
cryptsetup -v luksFormat /dev/loop7


Or using a detached header, it works to do this:

losetup /dev/loop6 header-file
cryptsetup -v luksFormat --header /dev/loop6 container
=====================================================================

I see that in the release notes for cryptsetup-1.5.1, it talks about "lazy
initializations."  Could this be the cause of this new behavior, and if
so, is this an expected trade-off in order to allow for some cryptsetup
operations to be run by non-root users?  I guess if you could clarify
whether this is expected new behavior or a bug, I would appreciate it.

Thank you,
Jason Daly

Re: [dm-crypt] Unexpected behavior in cryptsetup-1.5.1

[Milan Broz]

On 12/28/2012 04:22 PM, jason_daly@lavabit.com wrote:
> I see that in the release notes for cryptsetup-1.5.1, it talks about "lazy
> initializations."  Could this be the cause of this new behavior, and if
> so, is this an expected trade-off in order to allow for some cryptsetup
> operations to be run by non-root users?

Yes, it is caused by this change and it is a bug (and should be fixed
in devel tree already), so next release will work again here.

Your workaround (allocate loop in advance) should work always.

(You still need to be root for LUKS format...)

Thanks for report!

(You can directly use http://code.google.com/p/cryptsetup/issues/list next time
if you want track specific problem and the fix.)

Milan

Re: [dm-crypt] Unexpected behavior in cryptsetup-1.5.1

[Milan Broz]

On 12/28/2012 08:15 PM, Milan Broz wrote:
> On 12/28/2012 04:22 PM, jason_daly@lavabit.com wrote:
>> I see that in the release notes for cryptsetup-1.5.1, it talks about "lazy
>> initializations."  Could this be the cause of this new behavior, and if
>> so, is this an expected trade-off in order to allow for some cryptsetup
>> operations to be run by non-root users?
> 
> Yes, it is caused by this change and it is a bug (and should be fixed
> in devel tree already), so next release will work again here.

This was a new regression, some filesystems do not support O_DIRECT flag
(here it was tmpfs) so code now tries to workaround it by repeating
open without direct-io if it fails.

Fixed in git devel tree.

Thanks,
Milan