On 10/9/23 02:38, Andrei Borzenkov wrote:
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?
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
