From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FD002BB17 for ; Thu, 15 Jan 2026 02:59:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768445977; cv=none; b=T+kb/jb+g0At1agyp1yhrDaKDkvrcAWzDB1O6orNHfBmi3g+5RlBZL4WCHX2pbGl1sGMsFRUmV/X9CkKRduPVT4sy4oO2PGiMDfJ1QY6Q6+SQsVx4cfg7pdoSNMLpXitIWVk8i3ahCQGqTZhx0c22o9aV0diAdpNIX4wpZryAC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768445977; c=relaxed/simple; bh=7ZegbXocnJ1e8abILR6bdVGukvtVLEEKi9RIvZkynAc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oX7pryS0XrgzDN0fUELXpwAeezWq0k+qr0Rljhe2tTAiVLZWhzxVbKDrii95ygQQRIPtsH71On+Cbj//OWiKudKDe5Y810hmmYx7Iw8gLfBhunf05U0aA6LPFMTIpFIDGunajeRRH59fQb2PXUJbNp4aSlehRguxrGRg51yBX84= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=UmZb/53P; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="UmZb/53P" Received: from macsyma.thunk.org ([136.144.33.86]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 60F2xLwB031016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jan 2026 21:59:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1768445965; bh=dVwRIckv6hP7BPwU6nSlIw7mTHKhTypmIXbL7wDMCIM=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=UmZb/53P58ZLyeA6AB8w9g8xIw4S7dqR7SIXG0UyxVRyjb6oH3WghaHfWKX1aEGN+ 4bziNhDhod9dmddTCxz91s9onzKh/GTRYqwnsonVNnp8UBM4GMr1xXgQN7CYlHR78l 7vDeBw9h34OPPXTd98kybcp4ZO7SXSK7k43ILwiU5Lw4g2IA+KqsNfQ7PjlBhna+Jx pjtW2cxK+85iQQKoORnW0D/DSlEUN3ZGU7zBpOJaEi5bYdMyk9QWRKeZ29qyBxkPPw BjMzPp7YCYg6YBECvl/gclPKiTasHwaR1yI3au7XcWYsvJL3wsBf+NW5gJHI3CfgzI fFLs4FO/zubbw== Received: by macsyma.thunk.org (Postfix, from userid 15806) id 531EF54BBE79; Wed, 14 Jan 2026 17:59:20 -0900 (AKST) Date: Wed, 14 Jan 2026 17:59:20 -0900 From: "Theodore Tso" To: Nathan Royce Cc: LKML , linux-mm@kvack.org, Andrew Morton , Hugh Dickins Subject: Re: TmpFs Incorporation Of FsCrypt? Message-ID: <20260115025920.GB19200@macsyma.local> References: <20260114204352.GA19200@macsyma.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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