Bug 1491847

Summary:	[dracut] dropped to emergency shell after time-out for entering LUKS password
Product:	[Fedora] Fedora	Reporter:	Joachim Frieben <jfrieben>
Component:	dracut	Assignee:	dracut-maint-list
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	27	CC:	airlied, ajax, bskeggs, dracut-maint-list, eparis, esandeen, harald, hdegoede, ichavero, itamar, jarodwilson, jforbes, jglisse, jonathan, josef, jwboyer, kernel-maint, kparal, labbott, linville, mchehab, mjg59, nhorman, quintela, robatino, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-10-02 09:01:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Joachim Frieben 2017-09-14 20:08:06 UTC

Description of problem:
When not providing the password for a LUKS encrypted LVM volume during start-up, the system falls back to an emergency shell. Even though the encrypted volume is not accessible, the unencrypted boot partition can be mounted and accessed which might pave the way to injecting malicious code into the system.

Version-Release number of selected component (if applicable):
kernel-4.13.1-303.fc27

How reproducible:
Always

Steps to Reproduce:
1. Boot system.
2. Do not provide any input after password for LUKS encrypted volume has been requested.

Actual results:
System falls back to emergency shell.

Expected results:
System keeps waiting indefinitely for user input.

Additional info:
None

Comment 1 Laura Abbott 2017-09-14 21:43:08 UTC

Dropping to a shell is handled by dracut

Comment 2 Joachim Frieben 2017-09-14 22:23:03 UTC

Version-Release number of selected component (if applicable):
dracut-046-2.git20170811.fc27

Comment 3 Joachim Frieben 2017-09-22 03:15:04 UTC

Fedora 26 is -not- affected by this issue: the unlock panel keeps being displayed for hours without ever seeing a time-out. Relevant packages include

- dracut-046-2.git20170811.fc26
- kernel-4.12.13-300.fc26

This observation suggests that dracut is not the correct component.

Comment 4 Zbigniew Jędrzejewski-Szmek 2017-09-22 05:07:09 UTC

Can you paste your /etc/crypttab and /etc/fstab? Which systemd version do you have?

Comment 5 Joachim Frieben 2017-09-26 00:48:43 UTC

1. Contents of /etc/crypttab and of /etc/fstab turn out to be identical for Fedora 26 and Fedora 27. In principle, the should ensure that the system waits indefinitely for user input.

::::::::::::::
/etc/crypttab
::::::::::::::
luks-ABC UUID=XYZ none

::::::::::::::
/etc/fstab
::::::::::::::

#
# /etc/fstab
# Created by anaconda on Tue Sep 19 20:27:36 2017
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/noname-root /      ext4  defaults,x-systemd.device-timeout=0 1 1
UUID=XYZ /boot                 ext4  defaults        1 2
/dev/mapper/noname-home /home  ext4  defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/noname-var /var    ext4  defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/noname-swap swap   swap  defaults,x-systemd.device-timeout=0 0 0


2. Fedora 27 still features systemd-234-5.fc27 as of 2017-07-31.

Comment 6 Zbigniew Jędrzejewski-Szmek 2017-09-26 08:12:03 UTC

Seems to be https://github.com/systemd/systemd/issues/6402.

Comment 7 Joachim Frieben 2017-10-01 07:42:14 UTC

*** Bug 1495635 has been marked as a duplicate of this bug. ***

Comment 8 Kamil Páral 2017-10-02 09:01:08 UTC

I'm going to dupe this the other way around, because bug 1495635 has already been proposed a blocker, has lots of debugging info, and a response from the developer.

*** This bug has been marked as a duplicate of bug 1495635 ***