luksSuspend doesn't work

[GoogleCodeExporter]

I'm trying to suspend LUKS volume (on top of LVM, if this matters), and nothing 
happens: all accesses to this volume continues to work seamlessly without any 
blocking. Suspend of another LUKS volume created for testing (also LVM) works 
good.

Output with --debug and strace attached.

Original issue reported on code.google.com by lexsz...@gmail.com on 18 Nov 2013 at 8:01

Attachments:

• cryptsetup_debug.log
• cryptsetup_strace.log

[GoogleCodeExporter]

Sorry, bad strace log.

Original comment by lexsz...@gmail.com on 18 Nov 2013 at 8:26

Attachments:

• cryptsetup_strace.log

[GoogleCodeExporter]

From log:
# Active device has no UUID set, some parameters are not set.

How did you activate the device? luksSuspend can work only for LUKS devices 
activated by cryptsetup (which always set UUID).

Can you paste also "dmsetup info -c" ?

Original comment by gmazyl...@gmail.com on 18 Nov 2013 at 9:14

[GoogleCodeExporter]

I've used 'cryptmount' tool ( http://cryptmount.sourceforge.net/ )
According to 'dmsetup info -c' seems like it doesn't set any UUID.  I will 
report a bug to its authors.

Is it essential to have UUID for suspend/resume functionality?
Also, why does cryptsetup return 0 in this case, shouldn't it return some error 
code?

Original comment by lexsz...@gmail.com on 18 Nov 2013 at 9:51

[GoogleCodeExporter]

Yes, it is essential - in DM_UUID is encoded also LUKS uuid, so luksResume can 
check that you are using correct LUKS header to resume the device. (Otherwise 
wrong LUKS header/key can be used and you will get very serious data 
corruption.)

You can of course use dmsetup to suspend dmcrypt manually but then you have to 
provide plain key on resume as well...

(btw I thought cryptmount is just cryptsetup wrapper... so this should not 
happen.)

Original comment by gmazyl...@gmail.com on 18 Nov 2013 at 11:12

[GoogleCodeExporter]

So the cryptomount author seems to simply copied source code from cryptsetup 
instead of using libcryptsetup.

This is completely wrong, sorry, cannot help there...

Original comment by gmazyl...@gmail.com on 18 Nov 2013 at 11:19

• Changed state: Invalid

[GoogleCodeExporter]

Okay, and what about cryptsetup return code in case of this error?

Original comment by lexsz...@gmail.com on 19 Nov 2013 at 6:35

[GoogleCodeExporter]

Yes, there should be error message and error exit code. Will fix it...
(Some operation, like remove, will work though.)

Original comment by gmazyl...@gmail.com on 19 Nov 2013 at 1:47

[GoogleCodeExporter]

Actually, there was an error message but also bug which prevented to display it 
if device was used (cryptmount always mount the device).

Fixed (and added additional error message) in these commits
http://code.google.com/p/cryptsetup/source/detail?r=626801f7df6c9b65455c384e626e
5c3e26e86e5a
http://code.google.com/p/cryptsetup/source/detail?r=58b5be440f83afc1598fdce6589b
56f1353822a8

so now you should get
# cryptsetup luksSuspend x ; echo $?
Cannot determine device type. Incompatible activation of device?
This operation is supported only for LUKS device.
1

Original comment by gmazyl...@gmail.com on 19 Nov 2013 at 8:03

[GoogleCodeExporter]

Regarding the "completely wrong" copying of cryptsetup source-code within 
cryptmount; this arose for two main reasons:
* firstly, cryptmount added support (in mid-2008) for LUKS encryption *before* 
libcryptsetup was available (or stable, in early 2010?).
* secondly, the API provided by libcryptsetup is not well matched to the way 
cryptmount decouples management of encryption keys from device-mapper setup.
Clearly, it would be far better to use an API from cryptsetup to provide LUKS 
support within cryptmount, but this seems far from easy given the current 
architecture of the two tools. If a route could be found to avoid the copying 
of cryptsetup source-code within cryptmount, I would certainly be keen to move 
in that direction in future releases of cryptmount.
RW Penney.

Original comment by rwpab...@gmail.com on 11 Mar 2014 at 7:54