<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 4, 2018 at 5:47 PM Marek Howard <<a href="mailto:marekhwd@gmail.com">marekhwd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello.<br>
<br>
I'm trying to unlock my LUKS (type luks2) encrypted backup drive via<br>
udev rule /etc/udev/rules.d/99-unlock-backupdrive.rules:<br>
<br>
ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", \<br>
ENV{ID_SERIAL}=="FZ133888", ENV{ID_PART_ENTRY_UUID}=="8c347a-02", \<br>
RUN+="/root/unlock-backupdrive"<br>
<br></blockquote><div><br></div><div>You should just put an entry in /etc/crypttab instead, and let systemd-cryptsetup handle it via the existing dependencies mechanism.</div><div><br></div><div><font face="monospace, monospace"> backupdisk /dev/disk/by-partuuid/8c347a-02 /root/backupdrive.key nofail</font></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
# Keyslot 1 priority 1 != 2 (required), skipped.<br>
# Trying to open LUKS2 keyslot 0.<br>
# Reading keyslot area [0x8000].<br>
-# Userspace crypto wrapper cannot use aes-xts-plain64 (-95).<br>
-# Keyslot 0 (luks2) open failed with -95.<br>
+# Opening lock resource file /run/cryptsetup/L_8:18<br>
+# Acquiring read lock for device /dev/sdb2.<br>
+# Verifying read lock handle for device /dev/sdb2.<br>
+# Device /dev/sdb2 READ lock taken.<br>
[...SNIP...]<br>
# Releasing crypt device /dev/sdb2 context.<br>
# Releasing device-mapper backend.<br>
# Unlocking memory.<br>
-Command failed with code -1 (wrong or missing parameters).<br>
+Command successful.<br>
<br>
What could be the problem?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I've tried to unlock device via udisksctl:<br>
<br>
#!/bin/bash -x<br>
exec >/tmp/udisksctl-unlock.udev.log 2>&1<br>
udisksctl unlock -b $DEVNAME --key-file /root/backupdrive.key<br>
<br>
but that also failed with:<br>
<br>
Error looking up object for device /dev/sdb2<br>
<br>
although, again, it worked fine from xterm afterwards.<br></blockquote><div><br></div><div>udisksd only learns new devices after it has received udev's notification about them, which only happens after all rules have been processed.</div><div><br></div><div>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.)</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div></div>