Red Hat Bugzilla – Bug 845701
Crypttab does not mount volume at boot
Last modified: 2016-11-25 08:05:53 EST
I am coming from the "Community": Scientific Linux 6.2, 64 bit. Would one of our interpret heroes at Red Hat please fix this for me?
I just encrypted my backup drives. In the process, I found the /etc/crypttab ignores my entry for my backup drive, forcing an error at fstab time. I am forced to mount my backup drive with rc.local.
$ grep -i lin-bak /etc/crypttab
lin-bak /dev/sdb1 /etc/crypttab.lin-bak.key
$ grep -i lin-bak /etc/fstab
/dev/mapper/lin-bak /lin-bak ext4 defaults 1 0
fstab errors out with mount: "special device /dev/mapper/lin-bak does not exist". This error is what you would expect as /etc/crypttab does not create /dev/mapper/lin-bak. (/dev/mapper/lin-bak disappears after each reboot.)
There are no other errors other than the mount error at boot up.
My other UUID mounted drives (my main and swap drives) do get /dev/mapper entries and do mount correctly.
Here is my rc.local work around:
# if I can not get /etc/crypttab to work, this will populate /dev/mapper
# with lin-bak and mount /lin-bak
if [ ! -L /dev/mapper/lin-bak ]; then
cryptsetup luksOpen /dev/sdb1 lin-bak < /etc/crypttab.lin-bak.key
cryptsetup luksOpen /dev/sdb1 lin-bak -d /etc/crypttab.lin-bak.key
If not, your keyfile contains EOL (\n) and because keyfiles take EOL as normal char (while in interactive or pipe) input EOL causes end of input.
So in this case just trim your keyfile so it contain only chars before first \n - or change LUKS keyslot to use this keyfile.
(Check with "hexdump -c /etc/crypttab.lin-bak.key".)
# umount /lin-bak
# cryptsetup remove /dev/mapper/lin-bak
# cryptsetup luksOpen /dev/sdb1 lin-bak -d /etc/crypttab.lin-bak.key
No key available with this passphrase.
# cryptsetup luksOpen /dev/sdb1 lin-bak < /etc/crypttab.lin-bak.key
# hexdump -c /etc/crypttab.lin-bak.key
0000010 ... \n
At this point, I have to cry foul! "vi -b /etc/crypttab.lin-bak.key" shows this file to be a simple one line file. If I add a second empty line, hexdump gives me two "\n" at the end of the file. Since "vi" will not create a "\n" free file, how in the world am I to create a text file without a "\n" at the end?
And, more foul,
# hexdump -c < /etc/crypttab.lin-bak.key
0000010 ... \n
Which does work, also has a "\n" in it!
I am really confused!
More confusion, if I am not mistaken, if I find a way to remove the "\n", do I not get a 1024 character long file?
You can create it e.g.
echo -n "mypassword" >file
For removing \n... I would ether use dd (dd if=oldfile of=newfile bs=1 count=N-1) or something even more clever like... vi?
(first hit on google btw ;-)
If you use it as keyfile (luksAddKey for example) then the \n will be just part of keyfile.
So this is not bug, just quite problematic handling of \n in cryptsetup (which must be there for compatibility reasons...)
Maybe not a bug, but really bad programming. Who in the world in going to know they have to create the keyfile without the "\n"?
This there any chance you can use your considerable influence to get this fixed? If not, can you at least get something put into the man page on the "\n" free requirement and how to create a "\n" free keyfile?
I rebooted with my rc.local work around commented out. I am confirming that your fix works. /lin-bak mounted properly from fstab.
Thinking about the problem: I do believe that crypttab is expected to accept lie feeds (\n) as a possible password, so this is why I had the problem. That being the case, the \n feed requirement must be documented in the man page. Otherwise it is going to drive a lot of folks nuts, especially since I googled my eyeballs out and found nothing before reporting to you.
Should I open a new bug on the man page or can you just use this one and change the name?
see man cryptsetup - NOTES ON PASSPHRASE PROCESSING FOR LUKS section
crypttab has parameter for keyfile, so it is processed like a keyfile.
(but I do not maintain crypttab processing...)
Btw Debian crypttab man page has this:
The third field, key file, describes the file to use as a key for decrypting the data of the source device. Note that the entire key file will be used as the passphase; the passphase must not be followed by a newline character.
No idea why it is not in Fedora/RHEL man page. Reopen this bug it you want to fix man crypttab page (it is part of initscritps package).
(...and eventually RHEL can do it even without "passphase/passphrase" typos :-)
(In reply to comment #9)
> (...and eventually RHEL can do it even without "passphase/passphrase" typos
I went to publik skol! :-)
How about my question about correcting the man page? If you decide to do that, I will volunteer to write it. (You can fix my spelling and cherry it out)
Please move all activity on this bug to:
crypttab tab man page password section needs to be updated