Message-ID: <CALaQ_hpNLkWBxKbFdCKyE88OZvydFN1Wg7-sbr-yZ3vK3Anazg@mail.gmail.com>
Date: Thu, 15 Jan 2026 01:04:48 -0600
From: Nathan Royce <nroycea+kernel@...il.com>
To: Theodore Tso <tytso@....edu>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org, 
	Andrew Morton <akpm@...ux-foundation.org>, Hugh Dickins <hughd@...gle.com>
Subject: Re: TmpFs Incorporation Of FsCrypt?

On Wed, Jan 14, 2026 at 8:59 PM Theodore Tso <tytso@....edu> wrote:
> 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.

Ugh, okay. Thanks for that insight...
This is the flip-flopping that I'm talking about for myself, because
if it worked the way I was hoping, that was the real draw for me.
I just figured the inode structure might/could also be session-based,
or a mix of global/session.
I was surprised when you mentioned the ability to reclaim space from
encrypted cache, and went to look into it, and came across
https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data/
(even though it's ecryptfs).
It makes sense, and is a valid good reason for keeping fscrypt into
consideration over doing something like `homed` luks/btrfs loopback
file.
Thanks again for setting me straight with my misconception.

Powered by blists - more mailing lists