A directory can remain fully visible in a mounted Linux filesystem while its regular-file contents and filenames are unusable without a particular key. With fscrypt, that boundary is attached to filesystem objects rather than created by mounting a second encrypted filesystem. An encryption policy assigned to an empty directory is inherited by regular files, directories, and symbolic links created beneath it.
The property is narrower than full filesystem secrecy. fscrypt encrypts file contents and filenames, but most filesystem metadata remains visible, and ordinary permission checks continue to define who may access objects once the relevant key is present. Encryption policy and access control are therefore separate boundaries.
Policy is attached before the directory gains encrypted children
FS_IOC_SET_ENCRYPTION_POLICY assigns an fscrypt policy to an empty directory. The policy selects a contents encryption mode, a filenames encryption mode, flags, and a reference to the master key. New encrypted objects created in the tree inherit the policy according to the filesystem’s fscrypt rules.
The empty-directory requirement prevents an operation that would appear to encrypt existing plaintext files in place. fscrypt does not provide in-place conversion through this ioctl. Data must enter the encrypted tree through creation or migration under the established policy.
Policy inheritance also creates an enforcement property for directory structure. Except for special files such as named pipes, device nodes, and UNIX domain sockets, an encrypted directory tree cannot normally contain unencrypted files or files governed by a different encryption policy. Link and rename operations that would violate this policy relationship are rejected.
v2 policies identify keys through a derived identifier
For new encrypted directories, the kernel documentation specifies v2 policies. A v2 master key is added with FS_IOC_ADD_ENCRYPTION_KEY, and the kernel returns a 16-byte key identifier derived from the key. The policy stores that identifier rather than an arbitrary userspace-selected descriptor.
The identifier is not the encryption key and is not intended to be secret. Its role is stable key selection: the filesystem can associate encrypted objects with the master key needed to unlock them without storing the master key itself in the policy metadata.
v1 policies use a shorter key descriptor and have security and usability limitations documented by the kernel. New deployments should not treat v1 and v2 as interchangeable policy formats merely because both can refer to encrypted directory trees.
Per-file derivation limits direct reuse of master-key material
With the normal v2 design, fscrypt derives subkeys from a master key through its key derivation function. Per-file nonces contribute to key separation so that distinct files do not simply encrypt their contents with one identical raw key and IV construction.
Some policy flags change the derivation and IV model for specific storage requirements. FSCRYPT_POLICY_FLAG_DIRECT_KEY, FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64, and FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 have distinct constraints and are mutually exclusive. These modes are implementation choices with cryptographic consequences, not generic performance toggles.
The encryption mode is also split by data type. A policy selects one mode for file contents and another for filenames from combinations supported by the running kernel and filesystem. Hardware inline encryption can participate in the contents path, while filename encryption still requires kernel cryptographic processing.
Removing a key changes access, not on-disk policy
Adding the appropriate master key makes protected files available in plaintext form through normal filesystem operations, subject to ordinary authorization. Removing the key does not strip the encryption policy from the directory tree or decrypt its stored data. Instead, operations requiring plaintext content become unavailable while the key is absent.
Without the key, metadata operations can still expose information. stat() can report metadata, directories can be listed using encoded representations derived from encrypted names, and files can be deleted under documented conditions. Regular files cannot be opened or truncated without the key, and operations that require such a file descriptor consequently fail.
This behavior makes key absence a confidentiality boundary for covered content and names, not a general object-existence boundary. File sizes, permissions, timestamps, extended attributes, and other non-filename metadata are outside fscrypt’s main confidentiality guarantee.
Possession of a key does not replace filesystem authorization
A process that can cause a master key to be present does not thereby receive arbitrary read permission on every object protected by that key. VFS permission checks, ACLs, Linux Security Module policy, mount restrictions, and other authorization mechanisms continue to apply.
The reverse distinction also matters. A process may have mode-bit permission to a file but still be unable to open its plaintext content while the fscrypt key is absent. Access therefore depends on both cryptographic availability and the normal authorization path.
This separation is useful in multi-user storage designs because key lifecycle can be tied to a login or protected session while filesystem permissions continue to express object-level sharing. It also means that granting broad filesystem privilege to a process can weaken the isolation expected from a key-management design once keys are active.
Online compromise and offline exposure have different boundaries
fscrypt primarily addresses data-at-rest exposure. With a strong key, protected contents and filenames can remain confidential during a single point-in-time offline compromise of storage. The guarantee does not extend to all metadata, and it does not provide general authenticity against an attacker able to modify the filesystem offline before a later authorized access.
An online attacker with sufficient privilege can access plaintext while the relevant keys are active. Decrypted data can also exist in kernel caches, and key removal does not imply that every prior plaintext copy has been cryptographically erased from memory. Storage encryption therefore cannot substitute for process isolation or kernel integrity.
Hardware-wrapped keys can change part of the key-exposure model when supported by the platform and inline encryption stack. They keep certain key material wrapped outside the encryption hardware, but they carry hardware and policy constraints and do not turn fscrypt into protection against arbitrary kernel compromise.
Directory placement becomes part of the cryptographic architecture
Because policy is inherited through encrypted directory trees, the location where a policy begins determines which newly created objects enter that cryptographic domain. Moving data between policy domains is not equivalent to relabeling metadata; incompatible policy relationships are rejected, and migration generally requires plaintext access followed by creation under the destination policy.
A robust deployment consequently treats the top-level encrypted directories, their v2 policy identifiers, and master-key lifecycle as one coordinated boundary. fscrypt can protect file contents and names at rest, but its guarantees remain deliberately separate from filesystem authorization, metadata confidentiality, process confinement, and system integrity.