Question about a udev unlocker

[opoplawski]

I wonder what anyone's thoughts on a udev unlock rule like the following are:

ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", ENV{ID_BUS}=="usb", ENV{ID_FS_TYPE}=="crypto_LUKS", RUN+="/usr/bin/clevis luks unlock -d %E{DEVNAME}"

vs the systemd implementation which seem to accomplish the same thing. I can see the above failing for drives already attached at boot before the network is up. But it doesn't require an /etc/crypttab entry which I think the systemd implementation does.

[cbiedl]

@opoplawski Have you tried that? Because cryptsetup (within clevis-luks-unlock) failed, which after adding --debug which resulted in

# Userspace crypto wrapper cannot use aes-xts-plain64 (-95).

where I completely fail to see what's happening. Running that command manually or from a script created for that purpose succeeds. This leaves me in the assumption udev hides some information (name space?) so cryptsetup cannot do the job. Most likely candidate is this operation failing:

socket(AF_ALG, SOCK_SEQPACKET, 0) = -1 EAFNOSUPPORT (Address family not supported by protocol)

FWIW, thats a LUKSv2 formatted disk.

[opoplawski]

I believe it is working here. Likely with LUKSv1.

[opoplawski]

So, I'm back to poking at this again on EL9 and there seem to be several issues:

• It appears that the PATH for the RULE command does not include /usr/sbin so it failis to find cryptsetup: /usr/bin/clevis-luks-unlock: line 60: cryptsetup: command not found
• The udev man page indicates:

           Note that running programs that access the network or mount/unmount filesystems is
           not allowed inside of udev rules, due to the default sandbox that is enforced on
           systemd-udevd.service.

Which looks like the source of the EAFNOSUPPORT above?

[sergio-correia]

Would you please provide additional info so that I could try to reproduce the issue locally?

[opoplawski]

So I guess a tpm unlock might work if the path issue was resolved, but tang just wont.

[opoplawski]

So, you need a USB disk with a luks encrypted filesystem on it. Register a clevis unlock pin for it - we use tang. Use the above udev rule and attach the disk. Best debug method is probably to strace the systemd-udevd process, e.g.:

strace -f -o /var/tmp/udevd.strace -s 300 -p $(pidof systemd-udevd)

[opoplawski]

Yeah I'm seeing the sendmsg() call to the nameserver getting blocked with EPERM which is likely due to the sandbox described above, so tang is just not going to work.

[opoplawski]

Here's what I have now. udev rule:

ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", ENV{ID_BUS}=="usb", ENV{ID_FS_TYPE}=="crypto_LUKS", ENV{SYSTEMD_WANTS}="clevis-luks-unlock@$kernel.service"

[email protected]:

[Unit]
Description=Clevis decrypt disk /dev/%I
DefaultDependencies=no
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/clevis luks unlock -d /dev/%I

Couple recent changes - Drop RemainAfterExit - this was preventing the service from get re-triggered on re-insertion. Added After-network-online.target to help with reboots with the disk attached.