Eu criei o seguinte [email protected] service para 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
A idéia é descriptografar determinado dispositivo xxx criptografado pelo LUKS como xxx.luks apenas para um determinado usuário, que ativa o serviço com, por exemplo:
systemctl --user enable luks@xxx
Infelizmente, até testá-lo com
systemctl --user start luks@xxx
falha, pois sempre retorna com o código de saída 1 sem informar o motivo real. Para mim, ficou claro que o problema provavelmente está nas permissões. Ou seja, tenho certeza de que, para acionar manualmente cryptsetup luksOpen ... , é preciso elevar o shell, por exemplo, com sudo . De fato, se eu emitir
sudo systemctl start luks@xxx
funciona como um charme e similarmente
sudo systemctl enable luks@xxx
funcionaria para a fase de inicialização.
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.
Agora, estou ciente de pam_mount , que é capaz de realizar montagens semelhantes (que não posso usar porque não suporta cabeçalhos LUKS desanexados e porque monta dispositivos, algo que eu não quero) por usuário base e, de fato, pam_systemd lança systemctl --user , então definitivamente deve haver uma maneira de obter privilégios durante a inicialização por usuário para executar a descriptografia do dispositivo.
A propósito, os sintomas de falha de
systemctl --user enable luks@xxx
são ainda piores que os testes com
systemctl --user start luks@xxx
(que retorna apenas o código de saída 1 ). Isso é que eu não posso nem entrar com o usuário dado que se queixa de
Failed to create bus connection: No such file or directory
porque XDG_RUNTIME_DIR e DBUS_SESSION_BUS_ADDRESS não estão mais definidos, enquanto deveriam ter sido pelo serviço systemd-logind.service . Claramente, luks@xxx de alguma forma interrompe todo o processo de inicialização, mas devido a informações insuficientes no diário, não consigo identificar exatamente o motivo. Assim, minha suspeita atual sobre a falta de permissões ainda permanece.
Ansioso para propostas educadas. Obrigado.