Bug 1847751 - Clevis unlock of /etc/crypttab entries using device names fails
Summary: Clevis unlock of /etc/crypttab entries using device names fails
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: clevis
Version: 8.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 8.0
Assignee: Sergio Correia
QA Contact: Martin Zelený
URL:
Whiteboard:
Depends On:
Blocks: 1849593
TreeView+ depends on / blocked
 
Reported: 2020-06-16 23:06 UTC by Glenn Morris
Modified: 2020-06-29 23:54 UTC (History)
5 users (show)

Fixed In Version: clevis-13-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1849593 (view as bug list)
Environment:
Last Closed: 2020-06-29 23:54:24 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
CentOS 17470 None None None 2020-06-16 23:06:36 UTC

Description Glenn Morris 2020-06-16 23:06:37 UTC
Description of problem:
(This issue was found in CentOS 8.2, but seems like it must apply to RHEL also.)

Using Clevis at boot time to automatically unlock a non-root crypttab partition was working in 8.1, but failed in 8.2. There is no communication with the Tang server during boot.


Version-Release number of selected component (if applicable):
clevis-systemd-11-9.el8.x86_64


How reproducible:
Always.


Steps to Reproduce:
1. /etc/crypttab for non-root partition with entry of the form:
data1 /dev/vda5 none _netdev,timeout=60s

where /dev/vda5 is a luks1 partition.
Note the use of a device name in the second field, not UUID=.

2. Use clevis to bind this partition to a tang server for automatic unlock at boot time. In 8.1, this used: "systemctl enable clevis-luks-askpass.path".
In 8.2, this was replaced by a device-specific instance of the form clevis-luks-askpass@UUID.service.

3. Reboot.

Actual results:
No communication with Tang server at boot, partition is not unlocked.

Expected results:
Partition unlocked at boot.

Additional info:
/usr/libexec/clevis-luks-askpass sets the variable $d from the line:
  Id=cryptsetup:/
in /run/systemd/ask-password/ask.*
By experiment, this line comes from the second field in the /etc/crypttab file. If you use a device name in that file, the line
is of the form:
  Id=cryptsetup:/dev/vda5

In 8.2, clevis-luks-askpass compares this against the $device_uuid argument that was passed to the script instance via -l:
  [[ -n "${device_uuid}" ]] && [[ "${d}" != *"${device_uuid}"* ]] && continue

This will never match if you specified the device name in crypttab. Changing the crypttab file to use the UUID works.

Perhaps it would be fine to document that the UUID form is required.

Comment 2 Sergio Correia 2020-06-17 15:46:15 UTC
(In reply to Glenn Morris from comment #0)

[snip]

> In 8.2, clevis-luks-askpass compares this against the $device_uuid argument
> that was passed to the script instance via -l:
>   [[ -n "${device_uuid}" ]] && [[ "${d}" != *"${device_uuid}"* ]] && continue
> 
> This will never match if you specified the device name in crypttab. Changing
> the crypttab file to use the UUID works.
> 

Indeed. We need to get the UUID from $d before doing the comparison.
Thanks for the report, Glenn.


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