Bug 615503
| Summary: | RFE: fall back to asking for a password when keyfile doesn't exist | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nathanael Noblet <nathanael> | ||||
| Component: | systemd | Assignee: | systemd-maint | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | rawhide | CC: | iarlyy, johannbg, johannbg, jonathan, lpoetter, metherid, mschmidt, notting, plautrba | ||||
| Target Milestone: | --- | Keywords: | Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-04-27 03:12:32 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 784611 | ||||||
| Attachments: |
|
||||||
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. https://admin.fedoraproject.org/updates/FEDORA-2013-6070/systemd-202-2.fc19 systemd-202-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/systemd-202-3.fc19 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: https://admin.fedoraproject.org/updates/FEDORA-2013-6488/systemd-202-3.fc19 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. |
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: Always Steps to Reproduce: 1. Add a keyfile to /etc/crypttab 2. Don't have it available on boot 3. 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: