Red Hat Bugzilla – Bug 615503
RFE: fall back to asking for a password when keyfile doesn't exist
Last modified: 2013-04-26 23:12:35 EDT
Created attachment 432498 [details]
Patching rc.sysinit to attempt a password when the key is unavailable
Description of problem:
When configuring a luks encrypted partition/filesystem if you add a keyfile to it and add that to /etc/cryptab, if the keyfile isn't available, rc.sysinit doesn't give the user an attempt to enter the password.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add a keyfile to /etc/crypttab
2. Don't have it available on boot
Dropped to emergency shell
Fallback to requesting a password. Then perhaps after a few password attempts dropping to the shell would then be appropriate.
I'm not sure this is really a great fallback - it's essentially an invalid configuration.
Not really... I've configured a key that is stored on a usb stick, if it isn't plugged in in time I should still get a password prompt. That's why there are 8 password slots, you can have master keys, master passwords etc... Imagine a system where there is a master key on USB stored by maybe the manufacturer/supplier/support to unlock a device, but normally uses passwords.... lots of potential uses for a fallback.
or even if it was possible to specify a fallback method in the options portion of the crypttab ? So specify the path to a keyfile, but in the options specify that falling back to a password prompt is allowed..?
Given that systemd (which we use for crypttab in F-15 onwards) doesn't do this, I'm not intending to add this for initscripts for older releases.
Moving to systemd, where it could be considered as a RFE.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Is this still a problem or can this bug be closed or moved to an RFE?
I'd love to know if there is any way to have fallback/alternative unlock methods for encrypted partitions, however this particular bug could probably be cloased if this isn't the right medium to figure it out/discuss.
Adding this to fit and finish tracker bug.
Given that we will be only back porting important fixes for F15 at this point
in time I'm moving this RFE against Rawhide so it does not get forgotten or
lost in the EOL process.
systemd-202-2.fc19 has been submitted as an update for Fedora 19.
systemd-202-3.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-202-3.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
systemd-202-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.