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

[Aaron Rainbolt]

I figured out how to do this, sorta. I ended up bypassing the 
systemd-cryptsetup mechanism entirely and instead wrote my own shell 
script and systemd unit that did things exactly the way I wanted. Now if 
the user provides the right password, their home dir is mounted, if they 
type a wrong one they're asked for their password again, and if they 
type "guest" the system boots without mounting the encrypted home dir 
and uses the ramdisk-backed one instead.

In case anyone's interested, my systemd unit is:

[Unit]
Description=Mount encrypted home
Before=display-manager.service
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/local/bin/firebook_homemount.sh
[Install]
WantedBy=multi-user.target

And the corresponding script is:

#!/bin/bash
# Mounts an encrypted home dir (or fails gracefully)
while true; do
     decryptPassword="$(systemd-ask-password --no-tty "Please provide 
your user password (or type \"guest\" to enter guest mode)")"
     if [ "${decryptPassword}" = "guest" ]; then
         break
     else
         echo "${decryptPassword}" | cryptsetup luksOpen 
/dev/disk/by-label/firebook-crypt firebook-home
         if [ "$?" = "0" ]; then
             mount /dev/mapper/firebook-home /home
             break
         fi
     fi
done

I also masked systemd-ask-password-console.service and 
systemd-ask-password-wall.service so that if the user enters a wrong 
password, they're asked for their password within Plymouth repeatedly 
(whereas originally if the user flunked their password at Plymouth, 
systemd-ask-password would default to using 
systemd-ask-password-wall.service next). This seems to be working so far.

On 10/9/23 02:10, Aaron Rainbolt 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
>
> 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.
>
> 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
>