I've created the following luks@.service
service for systemd
:
[Unit]
Description=Cryptography Setup for '%I'
After=cryptsetup-pre.target
After=dev-mapper-%i.device
Before=cryptsetup.target
Before=umount.target
BindsTo=dev-mapper-%i.device
BindsTo=dev-mapper-%i.luks.device
Conflicts=umount.target
DefaultDependencies=no
IgnoreOnIsolate=true
RequiresMountsFor=/home
[Service]
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach '%I.luks' '/dev/mapper/%I' '%h/%I/secret.key' 'luks,header=%h/%I/header'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach '%I.luks'
KillMode=none
RemainAfterExit=yes
TimeoutSec=0
Type=oneshot
[Install]
WantedBy=default.target
The idea is to decrypt certain LUKS-encrypted xxx
device as xxx.luks
only for a given user, who enables the service with, for example:
systemctl --user enable luks@xxx
Unfortunately, even testing it with
systemctl --user start luks@xxx
fails as it always returns with exit code 1
without stating the actual reason. To me it was clear that the problem is likely in permissions. That is I know for sure that in order to manually trigger cryptsetup luksOpen ...
, one has to elevate the shell, e.g. with sudo
. Indeed, if I issue
sudo systemctl start luks@xxx
it works like a charm and similarly
sudo systemctl enable luks@xxx
would work for boot phase.
NOTE:
For such system-wide installation, it is of course needed to modify the service by replacing%h
with the actual home directory of a giver user, which is ugly and does not serve the final purpose anyway.
Now, I'm aware of pam_mount
which is capable of doing similar mounting (which I cannot use because it does not support detached LUKS headers and because it actually mounts devices, something what I don't want) on per user basis and, in fact, pam_systemd
launches systemctl --user
, so there definitely should be a way to obtain privileges during boot on per user basis to perform the device decryption.
By the way, failure symptoms of
systemctl --user enable luks@xxx
are even worse than those of testing it with
systemctl --user start luks@xxx
(which only returns exit code 1
). That is I cannot even log in with the given user as it complains about
Failed to create bus connection: No such file or directory
because XDG_RUNTIME_DIR
and DBUS_SESSION_BUS_ADDRESS
are not set anymore, while they should have been by the systemd-logind.service
service. Clearly, luks@xxx
somehow breaks the whole initialization process but due to insufficient information in journal, I cannot identify exactly why. Thus, my current suspicion about lack of permissions still remains.
Looking forward to educated proposals. Thank you.