Discussion:
cryptsetup open invoked from udev rule fails
(too old to reply)
Marek Howard
2018-11-04 15:46:46 UTC
Permalink
Hello.

I'm trying to unlock my LUKS (type luks2) encrypted backup drive via
udev rule /etc/udev/rules.d/99-unlock-backupdrive.rules:

ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", \
ENV{ID_SERIAL}=="FZ133888", ENV{ID_PART_ENTRY_UUID}=="8c347a-02", \
RUN+="/root/unlock-backupdrive"

The unlock-backupdrive script does just this:

#!/bin/bash -x
exec >/tmp/cryptsetup-open.udev.log 2>&1
cryptsetup open $DEVNAME backupdisk --key-file=/root/backupdrive.key--debug

The $DEVNAME is substituted with proper device file for the encrypted
partition. When I plug the USB drive, the script invoked from udev
fails with exit code 1 (logged in journal) but when I run the exact
same command line from xterm, it proceeds fine.

I've saved debug logs of both cases and here's the difference between
opening the disk from udev and from xterm (I've snipped debug messages
from xterm following acquiring the device lock):

--- cryptsetup-open.udev.log 2018-11-04 16:26:54.347968262 +0100
+++ cryptsetup-open.manual.log 2018-11-04 15:57:37.510608025 +0100
@@ -42,9 +42,46 @@
# Keyslot 1 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Reading keyslot area [0x8000].
-# Userspace crypto wrapper cannot use aes-xts-plain64 (-95).
-# Keyslot 0 (luks2) open failed with -95.
+# Opening lock resource file /run/cryptsetup/L_8:18
+# Acquiring read lock for device /dev/sdb2.
+# Verifying read lock handle for device /dev/sdb2.
+# Device /dev/sdb2 READ lock taken.
[...SNIP...]
# Releasing crypt device /dev/sdb2 context.
# Releasing device-mapper backend.
# Unlocking memory.
-Command failed with code -1 (wrong or missing parameters).
+Command successful.

What could be the problem?

I've tried to unlock device via udisksctl:

#!/bin/bash -x
exec >/tmp/udisksctl-unlock.udev.log 2>&1
udisksctl unlock -b $DEVNAME --key-file /root/backupdrive.key

but that also failed with:

Error looking up object for device /dev/sdb2

although, again, it worked fine from xterm afterwards.

Thank you for your replies!
Mantas Mikulėnas
2018-11-04 16:18:38 UTC
Permalink
Post by Marek Howard
Hello.
I'm trying to unlock my LUKS (type luks2) encrypted backup drive via
ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", \
ENV{ID_SERIAL}=="FZ133888", ENV{ID_PART_ENTRY_UUID}=="8c347a-02", \
RUN+="/root/unlock-backupdrive"
You should just put an entry in /etc/crypttab instead, and let
systemd-cryptsetup handle it via the existing dependencies mechanism.

backupdisk /dev/disk/by-partuuid/8c347a-02 /root/backupdrive.key nofail
Post by Marek Howard
# Keyslot 1 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Reading keyslot area [0x8000].
-# Userspace crypto wrapper cannot use aes-xts-plain64 (-95).
-# Keyslot 0 (luks2) open failed with -95.
+# Opening lock resource file /run/cryptsetup/L_8:18
+# Acquiring read lock for device /dev/sdb2.
+# Verifying read lock handle for device /dev/sdb2.
+# Device /dev/sdb2 READ lock taken.
[...SNIP...]
# Releasing crypt device /dev/sdb2 context.
# Releasing device-mapper backend.
# Unlocking memory.
-Command failed with code -1 (wrong or missing parameters).
+Command successful.
What could be the problem?
systemd-udevd.service has various "hardening" settings, among
them RestrictAddressFamilies= which disallows udev and its workers from
using AF_ALG, the kernel's cryptographic interface.
Post by Marek Howard
#!/bin/bash -x
exec >/tmp/udisksctl-unlock.udev.log 2>&1
udisksctl unlock -b $DEVNAME --key-file /root/backupdrive.key
Error looking up object for device /dev/sdb2
although, again, it worked fine from xterm afterwards.
udisksd only learns new devices after it has received udev's notification
about them, which only happens after all rules have been processed.

Or in other words, anything you do via udev rules happens *before* all
other daemons consider the device "ready". (After all, udev rules are often
what *make* the device ready for use.)
--
Mantas Mikulėnas
Marek Howard
2018-11-04 18:44:08 UTC
Permalink
So many revealings in one reply! Thank you very much for explaining it
in basic terms to me.
You should just put an entry in /etc/crypttab instead, and let systemd-cryptsetup handle it via the existing dependencies mechanism.
backupdisk /dev/disk/by-partuuid/8c347a-02 /root/backupdrive.key nofail
You're right, /etc/crypttab is the way and it works like charm after

systemd daemon-reload
systemd restart cryptsetup.target

Continue reading on narkive:
Loading...