Re: TmpFs Incorporation Of FsCrypt?

["Theodore Tso" <tytso@mit.edu>]

On Wed, Jan 14, 2026 at 05:32:22PM -0600, Nathan Royce wrote:
> What I like about fscrypt is it does appear to be session-based, so
> compared to LUKS, which just needs a key once to unlock it for
> everyone, fscrypt looks like it remains encrypted for everyone except
> the user that unlocked the path for that session.
> So if a user account maybe shares a path within their user path, with
> another user/group, a misconfiguration would supposedly keep an
> encrypted path still encrypted to the other shared user, even if the
> originating user has it unlocked for themselves.

Actually, no it doesn't work that way.  Access to the fscrypt key is
on based on the keyring, which is session based.  However, that key is
used to derive the per-file encryption key.  Once that key is
available, it's stashed in the in-memory inode structure --- and if
the file's unix permissions is world-readable, anyone will have access
to the file.

When the user logs out and the key is removed, we will iterate over
zap all of the encrypted inodes and dentries; see do_remove_key() and
try_to_lock_encrypted_keys() in fs/crypto/keyring.c.  So if you have a
ChromeOS device which is shared across multiple users in a family,
when Alice logs out of the ChromeOS laptop, and her brother Bob logs
into the laptop, this is the mechanism that prevents Bob from being
able to access Alice's files, even if Bob has a zero-day exploit,
given that Alice's master key is only available when Alice has
presented her password to the system, Bob won't be able to read's
Alice's secret dairy.

The main advantage of fscrypt and LUKS is that we can have separate
master keys for Alice and Bob, as opposed to having a single for the
entire dmcrypt device, as in the case for LUKS.  The other advantage
of fscrypt is that Alice and Bob can share the free space --- and
indeed, if Bob is logged into a ChromeOS device, and the free space is
almost exhausted (since if you have a very low-cost ChromeOS device
with only 32GB of flash, we can still reasonably share this device
across multiple users, since most of the user's data is stored in the
Cloud), what a root process can do is to find other users' Chrome
cache directories (e.g., such as Alice), and while the root process
which is managing ChromeOS's storage space, won't have access to
Alice's file contents, what the space management daemon *can* do is
delete the oldest files from directory that happens to be Alice's
cache directory, thus making space for Bob to cache more files in his
home directory.  Of course, then when Bob logs out, his cache files
might be subject for deletion when Alice starts using the machine,
even though Alice and Bob won't have access to their siblings' file
data.

Cheers,

					- Ted