[systemd-devel] cryptsetup open invoked from udev rule fails

[Marek Howard]

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!