[systemd-devel] What's the correct way to configure encrypted volume and mount point?

John Lane systemd at jelmail.com
Sat Jan 31 03:21:32 PST 2015


On 31/01/15 10:25, John Lane wrote:
> On 30/01/15 09:49, Jan Janssen wrote:
>>
>> But really: why not use automounting logic in fstab?:
>>     /dev/mapper/data /home/myuser/data ext4 noauto,x-systemd.automount 0 0
>>
>> No need to manually trigger a mount. And you can even use "noauto" in
>> crypttab so that the encrypted device is only opened once the mount point is
>> accessed the first time.
> Thanks Jan. as it happens, I've just been trying automount as a
> solution before I read your answer ;)
>
> But it leads me on to another question, if that's ok...
>
> I've set up an encrypted volume configured in crypttab/fstab with
> key/header on a path that is automounted.
> That path is on a encrypted removable usb "keyring" that's inserted at
> boot and everything works: the keyring is unlocked (passphrase
> requested) and mounted and then the other volumes are unlocked using
> their key/header on the keyring and mounted.
>
> However, after boot I want to pull out the keyring (it's only needed
> for the key/header during systemd-cryptsetup).
> But when I do this, the encrypted volume is unmounted and I don't want
> this to happen.
>
> Here's what I have in crypttab:
>
> |# <name>  <device>           <password>             <options>
> keyring   PARTLABEL=keyring  none                   noauto
> abc       /dev/lvm/abc       /root/keyring/abc.key  header=/root/keyring/abc.hdr
> xyz       /dev/lvm/xyz       /root/keyring/xyz.key  header=/root/keyring/xyz.hdr|
>
> and fstab:
>
> | <file system>     <dir>         <type>    <options>
> /dev/mapper/keyring /root/keyring ext4      ro,noauto,x-systemd.automount
> /dev/mapper/abc     /srv/abc      ext4
> /dev/mapper/xyz     /srv/xyz      ext4|
>
> I don't want to lose abc and xyz when I pull out keyring.
>
> I think it might be due to the
> "RequiresMountsFor=/root/keyring/abc.key" entries that systemd
> generates in the cryptsetup unit.
> I have tried using a drop-in to cancel that option:
>
> [Unit]
> RequiresMountsFor=
>
> but that didn't affect the setting, as I verified with
>
> $ systemctl daemon-reload
> $ systemctl show systemd-cryptsetup\@abc --property RequiresMountsFor
> RequiresMountsFor=/root/keyring/abc.key
>
> Do you know if/how I can achieve this functionality?
>
> Much appreciated,
> John
>
>
>
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Further to this, I tried manually creating a systemd-cryptsetup unit
instead of putting an entry in /etc/crypttab.
This allowed me to remove the "RequiresMountsFor" entry.

By doing this, removing the keyring doesn't unmount the encrypted volumes.

The unit I used looks like this:
/etc/systemd/system/systemd-cryptsetup at .service

    [Unit]
    Description=Cryptography Setup for %I
    Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8)
man:systemd-cryptsetup at .service(8)
    #SourcePath=/etc/crypttab
    DefaultDependencies=no
    Conflicts=umount.target
    BindsTo=dev-mapper-%i.device
    IgnoreOnIsolate=true
    After=cryptsetup-pre.target
    Before=cryptsetup.target
    #RequiresMountsFor=/root/keyring//%i.key
    BindsTo=dev-lvm-%i.device
    After=dev-lvm-%i.device
    Before=umount.target

    [Service]
    Type=oneshot
    RemainAfterExit=yes
    TimeoutSec=0
    ExecStart=/usr/lib/systemd/systemd-cryptsetup attach '%i'
'/dev/lvm/%i' '/root/keyring/%i.key' 'header=/root/keyring/%i.hdr'
    ExecStop=/usr/lib/systemd/systemd-cryptsetup detach '%i'

    [Install]
    WantedBy=dev-mapper-%i.device

I wonder if it's possible for an /etc/crypttab option to soften the
requirement for the mount to something like "StartRequiresMountsFor"...




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150131/07a630e6/attachment.html>


More information about the systemd-devel mailing list