TmpFs Incorporation Of FsCrypt?

TmpFs Incorporation Of FsCrypt?

[Nathan Royce]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

I recently saw the PRs for BTRFS relating to FSCRYPT, and thought I'd
explore the fscrypt package.

I started with `status` before moving to `setup` on the `/tmp` path which
is tmpfs.
As expected I'm sure, I got: `[ERROR] fscrypt setup: filesystem type tmpfs
is not supported for fscrypt setup`

Looking in https://github.com/google/fscrypt, I saw:
https://github.com/google/fscrypt/blob/ea916da7fa9844cc3da608e75510f478c7b09f7d/cli-tests/t_not_supported.sh
which coincides with my presumably expected error.

But I also saw: `The source files are located on an in-memory filesystem
such as tmpfs.` in the main README, which makes me wonder if there is
intent/plan to bring fscrypt to tmpfs.

I'm kind of thinking a use case of having keys and/or a password manager
database on external/encrypted storage, that gets transferred to some
random path in `/run/user/<#>` (tmpfs) on login where it is encrypted as
well (then the storage is unmounted/locked/removed), and the respective
program that uses the file(s) would point to a freshly generated config
that points to the random location.

[-- Attachment #2: Type: text/html, Size: 1408 bytes --]

Re: TmpFs Incorporation Of FsCrypt?

[Theodore Tso]

On Wed, Jan 14, 2026 at 01:03:20AM -0600, Nathan Royce wrote:
> But I also saw: `The source files are located on an in-memory filesystem
> such as tmpfs.` in the main README, which makes me wonder if there is
> intent/plan to bring fscrypt to tmpfs.
> 
> I'm kind of thinking a use case of having keys and/or a password manager
> database on external/encrypted storage, that gets transferred to some
> random path in `/run/user/<#>` (tmpfs) on login where it is encrypted as
> well (then the storage is unmounted/locked/removed), and the respective
> program that uses the file(s) would point to a freshly generated config
> that points to the random location.

I'm not aware of anyone considering adding fscrypt to tmpfs.  One
reason why it might not make sense is that the primary value that
fscrypt add is encryption at rest.  For example, if you are using
fscrypt to protect user files on a mobile phone, the file system level
encryption protects the data from being accessible immediately after
the phone is rebooted or power cycled.  Many of the attacks which
require direct access to the flash storage, or attempts to replace the
kernel with one special "enhancements" courtesy of the NSA, KGB,
Mossad, or MSS.

However, if there is a zero day vulnerability which allows the
attacker to compromise the currently running kernel without requiring
a reboot, and while the encryption keys are in memory because the user
is logged in --- fscrypt will likely not provide much protection.
That's because if the keys are loaded, and the decrypted file contents
are in the page cache, the only thing that prevents the attacker from
gaining access to the file contents is the Unix permissions, and the
system's discretionary access controls are very likely going to be
compromised if the kernel has been compromised.

This is why fscrypt for tmpfs might not be that useful.  Tmpfs is not
applicable for storage at rest.  So when you copy the encrypted files
from the persistent storage to the tmpfs, if you use fscrypt with
tmpfs, the only way it would add value is if you want to remove the
encryption keys from memory, without actually deleting the files from
tmpfs.  Otherwise, why not just zero the files and deleting the files
from tmpfs, and when the user logs back in, just copy the files from
the persistent storage into tmpfs?

Cheers,

					- Ted

TmpFs Incorporation Of FsCrypt?

[Nathan Royce]

I recently saw the PRs for BTRFS relating to FSCRYPT, and thought I'd
explore the fscrypt package.

I started with `status` before moving to `setup` on the `/tmp` path
which is tmpfs.
As expected I'm sure, I got: `[ERROR] fscrypt setup: filesystem type
tmpfs is not supported for fscrypt setup`

Looking in https://github.com/google/fscrypt, I saw:
https://github.com/google/fscrypt/blob/ea916da7fa9844cc3da608e75510f478c7b09f7d/cli-tests/t_not_supported.sh
which coincides with my presumably expected error.

But I also saw: `The source files are located on an in-memory
filesystem such as tmpfs.` in the main README, which makes me wonder
if there is intent/plan to bring fscrypt to tmpfs.

I'm kind of thinking a use case of having keys and/or a password
manager database on external/encrypted storage, that gets transferred
to some random path in `/run/user/<#>` (tmpfs) on login where it is
encrypted as well (then the storage is unmounted/locked/removed), and
the respective program that uses the file(s) would point to a freshly
generated config that points to the random location.