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

[Mantas Mikulėnas]

On Sun, Nov 4, 2018 at 5:47 PM Marek Howard <marekhwd at gmail.com> wrote:

> 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"
>
>
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


>  # 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.


> 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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20181104/ebc2af2f/attachment.html>