Bug 751640 - dracut ignores crypttab keyfile
Summary: dracut ignores crypttab keyfile
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-06 22:22 UTC by Lukas Bezdicka
Modified: 2014-01-20 07:18 UTC (History)
5 users (show)

Fixed In Version: dracut-013-19.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-23 23:28:56 UTC
Type: ---


Attachments (Terms of Use)

Description Lukas Bezdicka 2011-11-06 22:22:04 UTC
Description of problem:
dracut creates initscripts that ignore keyfile option in crypttab

/usr/share/dracut/modules.d/90crypt/cryptroot-ask.sh does not compy with crypttab(5) where it's said: 
       The third field specifies the encryption password.  If the field is not
       present or the password is set to none, the password has to be manually
       entered  during  system  boot.  Otherwise the field is interpreted as a
       path to a file containing the encryption password.  For swap encryption
       /dev/urandom  or  the hardware device /dev/hw_random can be used as the
       password file; using /dev/random may prevent  boot  completion  if  the
       system  does not have enough entropy to generate a truly random encryp‐
       tion key.

Comment 1 Harald Hoyer 2011-11-07 08:52:06 UTC
Yes, but what is your use case?
Including a password file in the initramfs does not help security...

Comment 2 Lukas Bezdicka 2011-11-07 14:34:48 UTC
Usecase is quite stupid I know, I have 1TB of encrypted data and I recently moved it to safe enough location, but I don't have resources to store data somewhere else while I'll remove encryption. Is there way to drop encryption without data loss?

Comment 3 Harald Hoyer 2011-11-07 16:54:55 UTC
(In reply to comment #2)
> Usecase is quite stupid I know, I have 1TB of encrypted data and I recently
> moved it to safe enough location, but I don't have resources to store data
> somewhere else while I'll remove encryption. Is there way to drop encryption
> without data loss?

and why does the data have to be decrypted during the initramfs boot phase and not later on?

Comment 4 Lukas Bezdicka 2011-11-10 18:47:53 UTC
probably later. It should be ok if systemd took care of it but I guess it ignores crypttab too and as it wants to mount that disk, it fails.

Comment 5 Harald Hoyer 2011-11-11 13:46:41 UTC
(In reply to comment #4)
> probably later. It should be ok if systemd took care of it but I guess it
> ignores crypttab too and as it wants to mount that disk, it fails.

no, systemd is fine with crypttab

Comment 6 Lukas Bezdicka 2011-11-12 22:46:40 UTC
Hey, it is a bug because system does not boot, you say that systemd is fine so why it won't boot? Than it has to be dracut as it stops and waits for user input. Should I open bugreport on systemd?

Comment 7 Harald Hoyer 2011-11-15 08:30:21 UTC
(In reply to comment #6)
> Hey, it is a bug because system does not boot, you say that systemd is fine so
> why it won't boot? Than it has to be dracut as it stops and waits for user
> input. Should I open bugreport on systemd?

1. please show me your kernel command line
2. please boot without "rhgb" and "quiet" on the kernel command line
   Do you see "Welcome to ..." ? If yes, then systemd is running and dracut has
   finished

Comment 8 Lukas Bezdicka 2011-11-15 12:40:39 UTC
I looked on machine's setup so:
- root is on raid md0
- md0 consists of: 30gb volume on sda and 30gb volume on LVM
- LVM disk is encrypted

so by documentation shis should work and yes it's mad :(

Comment 9 Harald Hoyer 2011-11-15 15:29:20 UTC
ok, try this:

# dracut --install <my_password_file> /boot/initramfs-<kernel_version>.img <kernel_version>

...

I will fix dracut, so that you can put 
install_items=" <my_password_file> "
in /etc/dracut.conf.d/99-mypwfile.conf

Comment 10 Lukas Bezdicka 2011-11-16 08:15:55 UTC
well for now I see only ./sbin/cryptroot-ask in initrd, which does not seem to be capable of opening encrypted device with key from file. But yes it worked and I have key file in initrd.

Comment 11 Fedora Update System 2011-11-17 10:36:20 UTC
dracut-013-19.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/dracut-013-19.fc16

Comment 12 Fedora Update System 2011-11-19 06:00:21 UTC
Package dracut-013-19.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-013-19.fc16'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16098/dracut-013-19.fc16
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2011-11-23 23:28:56 UTC
dracut-013-19.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Lukas Bezdicka 2011-11-30 18:42:05 UTC
Today I got to the machine and after update it worked fine. Thank you.

Comment 15 John Villalovos 2013-07-27 21:35:11 UTC
I updated to Fedora 18 and this seemed to stop working.  I have to type my password again.  Anyone else see this?

Comment 16 John Villalovos 2013-07-27 22:29:14 UTC
(In reply to John Villalovos from comment #15)
> I updated to Fedora 18 and this seemed to stop working.  I have to type my
> password again.  Anyone else see this?

I think I figured out the issue.  dracut doesn't seem to be copying /etc/crypttab into the initrd.  I'll look and see if there is a bug on that.

I created my dracut file by just doing:
# dracut --force

My keyfile got copied but not the /etc/crypttab :(

But I was having this issue after doing the upgrade and I did not manually run dracut.  I have fixed the issue temporarily by doing:
# dracut --force --install /etc/crypttab

Comment 17 John Villalovos 2013-07-27 22:39:34 UTC
My initial theory is that this commit broke things for the use case of this BZ:
commit 3d12d7a2cc5d4fc76ac87514dae2ab27bac8208c
Author: Harald Hoyer <harald@redhat.com>
Date:   Mon Sep 24 13:15:08 2012 +0200

    crypt: install /etc/crypttab only in host-only mode

diff --git a/modules.d/90crypt/module-setup.sh b/modules.d/90crypt/module-setup.sh
index 485cbe0..5c1c71b 100755
--- a/modules.d/90crypt/module-setup.sh
+++ b/modules.d/90crypt/module-setup.sh
@@ -47,7 +47,7 @@ install() {
     inst_hook cmdline 10 "$moddir/parse-keydev.sh"
     inst_hook cmdline 30 "$moddir/parse-crypt.sh"
     inst_hook cleanup 30 "$moddir/crypt-cleanup.sh"
-    inst_simple /etc/crypttab
+    [[ $hostonly ]]  && inst_simple /etc/crypttab
     inst_simple "$moddir/crypt-lib.sh" "/lib/dracut-crypt-lib.sh"

     dracut_install -o \

Comment 18 John Villalovos 2013-07-27 22:48:30 UTC
My workaround to fix this issue was to do this:
# cat /etc/dracut.conf.d/99-mypwfile.conf
install_items="/etc/<my_password_file> /etc/crypttab"

After doing that both my passphrase file and /etc/crypttab were copied into the initrd.

Hopefully that helps someone else who runs into this.


Note You need to log in before you can comment on or make changes to this bug.