Empty keyfile still allows dev creation and mounting

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Install cryptsetup mechanism (Ubuntu 8.04 LTS installs version 1.0.5)
2. Create keyfile and register the keyfile using 'sudo cryptsetup luksAddKey 
/dev/sdX /root/keyfile' to avoid interaction during startup
3. Reboot system => all works fine, unlock is successful, I get a 
/dev/mapper/crypt device and I can mount the encrypted drive and access the 
content.
4. Put the original keyfile aside and re-create an EMPTY keyfile (using command 
'touch keyfile'), with the correct permissions (400)
5. Reboot system => ALL STILL WORKS FINE => ????

What is the expected output? What do you see instead?

In case of an empty keyfile, I expect the initial devmapper creation to fail 
during start-up (after the default 3-times-trial).  But that doesn't happen.  I 
see a "normal" /dev/mapper/crypt device created and I can mount that device too!

What version of the product are you using? On what operating system?

Initially, I used the default version installed by Ubuntu 8.04 LTS, using 'sudo 
apt-get install cryptsetup'.  That was version 1.0.5.
Then, after detecting the flow, I compiled and installed the very latest 
version of cryptsetup, 1.4.1, hoping this issue would have been solved already. 
 However, it apparenly isn't.

Please provide any additional information below.

Original issue reported on code.google.com by geert.va...@gmail.com on 9 Mar 2012 at 6:18

[GoogleCodeExporter]

Is it LUKS device or plain device? Paste /etc/crypttab.

For plain device this is normal (it cannot check if key is correct, so it 
simply create new one), for LUKS it must fail.

(For plain crypt, IOW "create" command, it simply generate key from keyfile. So 
you have device, but there should be just rubbish in it. LUKS has mechanism to 
check that encryption key is valid for device.)

Check "dmsetup table --showkeys" before and after keyfile change - does it 
differ? (do not paste it here though, it is your encryption key :)

Original comment by gmazyl...@gmail.com on 9 Mar 2012 at 9:16

[GoogleCodeExporter]

And please reproduce this without rebooting please, IOW

1) luksFormat with keyfile
2) add keyfile
3) switch keyfile
4) try to open with new keyfile.

Also check that you do not use keyfile copy  in initramfs or something like that

(And this is definitely bugreport through Ubuntu, but I am almost sure they 
will close it as no longer supported distro version...)

Original comment by gmazyl...@gmail.com on 9 Mar 2012 at 9:39

[GoogleCodeExporter]

As for your first request: Sorry, forgot to mention the type of device.  It's 
indeed LUKS.

This is the content of the /etc/crypttab file:

# <target name> <source device> <key file>    <options>
  crypt         /dev/sdd1       /root/keyfile luks

The test with dmsetup will be done ASAP.

As for your 2nd request: will take some more time, but I'll come back on this 
one ASAP too.

Original comment by geert.va...@gmail.com on 9 Mar 2012 at 1:29

[GoogleCodeExporter]

Thanks.
ok, so with LUKS this should be impossible - I guess there is some other 
problem.

If you can, add --debug to cryptsetup commands, it should print many 
information what it is going on (check what is boot really doing - I do not use 
Ubuntu so cannot help much here).
I really need reproducer just with upstream binary if there is a problem.

Original comment by gmazyl...@gmail.com on 9 Mar 2012 at 2:14

[GoogleCodeExporter]

No info provided, I guess it was just operator mistake...
Please reopen if you think there is still a bug (and provide requested info), 
thanks.

Original comment by gmazyl...@gmail.com on 29 Mar 2012 at 9:29

• Changed state: Invalid

[GoogleCodeExporter]

I'm sorry to be ignorant to the promise I made a while ago to provide you with 
the info asked for, but I simply haven't had the time to re-check the 
situation.  I hate to use the word, but I'm currently very busy with higher 
priority things that eat up all my time.
The moment it becomes possible, I'll for sure come back on the issue.

Original comment by geert.va...@gmail.com on 30 Mar 2012 at 4:40

[GoogleCodeExporter]

No problem, just reopen it later if you are able to reproduce it with 
cryptsetup binary (without boot magic which is distro dependent).

Original comment by gmazyl...@gmail.com on 30 Mar 2012 at 5:00