[systemd-devel] How to make an encrypted disk mentioned in /etc/crypttab "optional"?

[Aaron Rainbolt]

On 10/9/23 02:38, Andrei Borzenkov wrote:
> On Mon, Oct 9, 2023 at 10:10 AM Aaron Rainbolt <arraybolt3 at gmail.com> wrote:
>> Good morning/evening, and thanks for your time.
>>
>> I'm attempting to create a Fedora-based immutable distro (not based on
>> Silverblue) that stores user data in an encrypted /home partition. The
>> goal is to have something that behaves somewhat similar to Chrome OS.
>> One feature I'm attempting to implement is a "guest mode", whereby a
>> user can sign into the system without providing any password, but if
>> they do so they don't gain access to the system's owner's data and
>> virtually anything they do is erased upon shutdown.
>>
>> In order to do this, I have two /home directories - one is part of the
>> (immutable) root filesystem, which can only be written to thanks to a
>> Dracut-created ramdisk overlay. The other is stored in an encrypted
>> partition. I'm using a crypttab line like this to prepare the encrypted
>> partition:
>>
>>       firebook-home LABEL=firebook-crypt none luks,discard,nofail
>>
>> And I'm using an fstab line like this to mount it:
>>
>>       /dev/mapper/firebook-home /home ext4 defaults,nofail 0 0
>>
> Where is your user home directory located?

That's slightly complicated, since there's two of them in this setup.

The root filesystem is a squashfs. Dracut mounts it at boot and applies 
a ramdisk overlay so that changes can be written to the root filesystem 
but they are all lost at shutdown. I have one /home directory in this 
squashfs, which has a subdirectory /home/user for the user account.

However, I also have a partition with the label "firebook-crypt" that is 
set up as /dev/mapper/firebook-home. It is mounted at /home (hiding the 
/home that is backed by the ramfs overlay) and contains it's own "user" 
directory. So basically if the system boots with the encrypted disk 
mounted, /home is backed by a LUKS partition, otherwise it is backed by 
a ramdisk overlay.

>> Note that I've marked both of these with "nofail" - the goal is that the
>> user will be prompted for their password by systemd upon boot, but if
>> they do not provide the password (by intentionally providing a wrong
>> password three times), the encrypted drive should not be mounted and the
>> system should boot normally using the ephemeral home directory provided
>> by the root filesystem + ramdisk overlay.
>>
> I am not sure whether systemd can even express such logic. Check
> whether any service involved in logging in has dependency on /home
> (like RequiresMountsFor=/home).
Will do, thanks!
>> This seems to be *almost* working, however if I intentionally provide a
>> wrong password to the password prompt a few times, it doesn't actually
>> "give up" on getting a password from me. What it does instead is it
>> stops asking me for the password at boot, but then rather than starting
>> GNOME it just leaves me at a console screen. If I am able to get GDM to
>> appear somehow, I can't sign in.
>>
>> What I end up doing is switching to a TTY, signing in, and then
>> elevating to root to troubleshoot. Once I've elevated to root, I get a
>> `wall` message informing me that the system is *still waiting* for a
>> password and that I need to run `systemd-tty-ask-password-agent` (I
>> think?) to provide it. If I go ahead and do this, then restart GDM, I'm
>> able to sign in after that. (I could be wrong about what command it's
>> asking me to run, but I think it was `systemd-tty-ask-password-agent`.)
>>
>>   From my research, it looks like systemd is refusing to ever truly "give
>> up" on getting the password for the encrypted /home directory, despite
>> the use of `nofail` in the fstab and crypttab files. I'm not finding any
>> documentation on how to get systemd to "give up" on getting the
>> password. For my particular use case, I'd like systemd to just forget
>> that the encrypted drive exists at all if the wrong password is given.
>> If the user wants to mount the encrypted drive after that, they should
>> either reboot or use cryptsetup manually.
>>
>> Is there any way to make systemd "give up" on getting a password?
>>
>> Thanks for your help!
>>
>> Aaron
>>