You are not logged in.

#1 2018-02-16 22:39:33

spuddie
Member
Registered: 2018-02-16
Posts: 3

struggling with dm-crypt...

Hi,

I'm a long-time Debian user (17 years...), finally switching to Arch. I'm using the occasion (setting up a new system) to encrypt some of my partitions with dm-crypt/luks. One of those partitions serves for backups. I want to decrypt+mount when backing up stuff and umount+crypt when that's done.

I have the following in /etc/crypttab:
backup    UUID=xxxxxxxx    /path/to/key    luks,noauto

and in /etc/fstab:
/dev/mapper/backup    /media/backup    ext4    defaults,noauto,x-systemd.automount    0 2


When booting the system, I find /media/backup unmounted, cryptsetup status backup gives "inactive" and systemctl status media-backup.automount says "active (waiting)".

ls /media/backup takes a couple of seconds (normal) and gives the expected output. Hurray! However, this is only step 1.

When I go "umount /media/backup", cryptsetup status backup shows the decryption is still active (not sure what the correct lingo here is). If I complete   the transaction with cryptsetup close backup, all diagnostics return to the status immediately after boot. A somewhat smaller hurray.

The problem is that after this first iteration, a new "ls /media/backup" doesn't do the autmount anymore: cannot access /media/backup: no such device.


An easy workaround would be to remove the crypttab/fstab lines, write 2 2-line bash scripts to do the mounting and the unmounting and forget the entire thing. But I do want to ask the community: What am I doing wrong; is there a more elegant fix to my problem?

I understand that from a security point of view this is somewhat academic: the decryption key is stored on another encrypted partition, but if someone gets access to my running system, they would gain access to my backup partition, whether it is decrypted at that point in time or not. if someone would gain access to a not-running system or only take the disk, the encryption is enforced.

However, I still find the question worth asking, even if it is mostly academical and even if I already have an easy workaround (that would have taken me less time then to type up this post).

Offline

#2 2018-02-16 22:56:14

loqs
Member
Registered: 2014-03-06
Posts: 17,372

Re: struggling with dm-crypt...

Welcome to the arch linux forums spuddie.  Note sure if it will help have you tried the TimeoutIdleSec option https://www.freedesktop.org/software/sy … mount.html

Offline

#3 2018-02-18 10:50:08

spuddie
Member
Registered: 2018-02-16
Posts: 3

Re: struggling with dm-crypt...

Hi, thx for the suggestion, but that didn't help. I'll just go with the workaround; still interested in a possible answer though.

Offline

#4 2018-02-18 11:27:59

frostschutz
Member
Registered: 2013-11-15
Posts: 1,418

Re: struggling with dm-crypt...

If it doesn't go away with systemd-umount either, then I guess - it's just not part of the concept? Perhaps it's able to resolve the dependency on mount but doesn't have a reverse-dependency on umount.

Sometimes it's intentional to have an active crypt container that isn't mounted (nor swap, lvm, ...). For example I have one such container to act as a key for other containers. So it's not as simple as closing all containers that don't seem to be in use...

For my backups I do it the same way, custom mount / umount script that handles it on demand.

Offline

#5 2018-02-18 12:16:30

spuddie
Member
Registered: 2018-02-16
Posts: 3

Re: struggling with dm-crypt...

In the mean while I understand why it happens: the service systemctl-cryptsetup@backup.service remains active after cryptsetup close, hence the decryption isn't triggered again. This would make a good start into fixing the problem in a systemd way (just using systemd-umount, which I didn't know before, might already do the trick, can't test that easily anymore).

As said before: I'go with manual mount/unmount scripts, it's actually not even a workaround, it's a simpler solution than a complicated systemd configuration.

thanks!

Offline

Board footer

Powered by FluxBB