Bug 615503 - RFE: fall back to asking for a password when keyfile doesn't exist
Summary: RFE: fall back to asking for a password when keyfile doesn't exist
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
Keywords: Triaged
Depends On:
Blocks: systemd-RFE
TreeView+ depends on / blocked
Reported: 2010-07-16 20:55 UTC by Nathanael Noblet
Modified: 2013-04-27 03:12 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-27 03:12:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patching rc.sysinit to attempt a password when the key is unavailable (350 bytes, application/octet-stream)
2010-07-16 20:55 UTC, Nathanael Noblet
no flags Details

Description Nathanael Noblet 2010-07-16 20:55:17 UTC
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):

How reproducible:

Steps to Reproduce:
1. Add a keyfile to /etc/crypttab
2. Don't have it available on boot
Actual results:
Dropped to emergency shell

Expected results:
Fallback to requesting a password. Then perhaps after a few password attempts dropping to the shell would then be appropriate.

Additional info:

Comment 1 Bill Nottingham 2010-07-26 17:55:33 UTC
I'm not sure this is really a great fallback - it's essentially an invalid configuration.

Comment 2 Nathanael Noblet 2010-07-26 20:17:39 UTC
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.

Comment 3 Nathanael Noblet 2010-08-25 19:28:42 UTC
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..?

Comment 4 Bill Nottingham 2011-02-28 20:39:35 UTC
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.

Comment 5 Fedora Admin XMLRPC Client 2011-10-20 16:29:18 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Jóhann B. Guðmundsson 2012-01-24 11:23:05 UTC
Is this still a problem or can this bug be closed or moved to an RFE?

Comment 7 Nathanael Noblet 2012-01-24 21:20:22 UTC
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.

Comment 8 Jóhann B. Guðmundsson 2012-01-26 22:02:28 UTC
Adding this to fit and finish tracker bug.

Comment 9 Jóhann B. Guðmundsson 2012-02-20 11:51:38 UTC
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.

Comment 10 Fedora Update System 2013-04-22 07:13:19 UTC
systemd-202-2.fc19 has been submitted as an update for Fedora 19.

Comment 11 Fedora Update System 2013-04-24 13:09:14 UTC
systemd-202-3.fc19 has been submitted as an update for Fedora 19.

Comment 12 Fedora Update System 2013-04-24 16:34:09 UTC
Package systemd-202-3.fc19:
* 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).

Comment 13 Fedora Update System 2013-04-27 03:12:35 UTC
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.

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