Re: How to make an encrypted disk mentioned in /etc/crypttab "optional"?

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Mon, Oct 9, 2023 at 10:10 AM Aaron Rainbolt <arraybolt3@xxxxxxxxx> 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?

> 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).

> 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
>