1

Here's what I'd like to do. Use autofs to automount an encrypted luks image file when the target directory is accessed.

I've been playing with both fstab and crypttab, but to no luck.

I do NOT want to use a key file to decrypt it. A password prompt window should appear when attempting to query the target mount folder /encrypted. cryptsetup should be mounting a file located at /secret/data.img which is a LUKS formatted file that once decrypted contains an ETX4 file system. That file system should then be mounted at /encrypted, but only after prompting the user for its password.

Bonus question, after a period of idle(timeout) inactivity, autofs should be closing the luks volume so that further access requires reentering the key.

Can this be done?

Here is my current fstab and crypttab.

--FSTAB--

UUID=11111111-2222-3333-4444-555555555555 /encrypted ext4 defaults,auto,x-systemd.automount,uid=1234,gid=1234,cache=no,rw 0 0

--CRYPTTAB--

trust-no-1 /secret/data.img none auto,rw

There are no questions that contain both autofs and luks keywords. Is this even possible?

JDMcMillian
  • 121
  • 5

1 Answers1

0

When you specify the x-systemd.automount option in /etc/fstab, you are effectively calling for creation of a systemd .automount unit. It provides automount functionality, but it has nothing at all to do with the classic autofs subsystem.

The problem is, neither the classic autofs nor the newer systemd .automount unit are part of the user session (or any interactive session at all), so they cannot easily present a password prompt. You would need a service that has a system part for actually doing the mount, and a user interface component that runs as part of the user session. Something like the D-Bus could be used for communication between them.

udisks would be the closest existing solution, but I'm not sure it even attempts to handle encrypted image files in the way you're envisioning. Even if it did, it would need the information that the mount point /encrypted is to be associated with the encrypted image /secret/data.img. But there can be multiple users on the system: popping up a passphrase input dialog for anyone/everyone whenever someone attempts to access /encrypted would reveal to all users that something encrypted exists on the system, which would be undesirable in some situations...

Your combination of fstab and crypttab cannot possibly satisfy your requirements, because fstab is referring to the encrypted image by filesystem UUID... but until the encryption is unlocked, that filesystem UUID is nowhere to be seen. So the automount unit that would be generated based on that fstab line will see on activation that there is no filesystem with that UUID and conclude that either the device is missing or there is an error on the fstab line.

There is nothing that would serve as a clue that the crypttab line would relate to that fstab line: the connection between those two configuration lines will be discoverable only after the encryption is already unlocked.

The crypttab option auto does not seem to be standard (yet?). Its opposite, noauto, exists in Debian (at least) but it means the encrypted device/image should be ignored during the system boot process. So by extension, auto would mean "activate this crypttab entry during the system boot process", which is the default... and also is the opposite of what you wanted to happen. If your (unspecified) distribution has defined this keyword in some other way, then you would have to rely on distribution-specific documentation; I cannot guess the exact technical meaning of that option.

telcoM
  • 87,318
  • 3
  • 112
  • 232