fs-verity Adds Runtime File Integrity With a Narrow Trust Scope
File permissions answer who may change a file. They do not prove that an allowed reader received the file the application expected. Linux fs-verity adds a filesystem-level integrity mechanism for individual read-only files. It can make silent disk corruption or an unauthorised content change visible at read time, provided the application verifies the digest against a trusted value.
When enabled on a supported filesystem, fs-verity builds a Merkle tree over the file and stores the tree in filesystem-specific metadata. Later reads verify data against that tree. A mismatch causes reads of the affected page to fail with EIO, and memory-map access can raise SIGBUS. The base mechanism is integrity protection; authenticity requires an external trusted digest or a verified signature.
The digest covers more than a bare content hash. It incorporates the Merkle root and file metadata such as size. An application should compare the complete fs-verity digest using the documented interface, not assume that a SHA-256 of the first block is equivalent. The expected value must come from a trusted deployment record, signed package metadata or another authenticated source.
Enabling verification is also a transition. The feature should be enabled before the file is trusted, and the expected digest must be recorded at the same point. A workflow that lets an attacker modify the file, enables fs-verity afterward and then trusts the resulting digest has verified the attacker's state.
fs-verity protects individual files. It does not make a directory immutable, stop a process with enough privilege from replacing a file name or protect a file before verification is active. A mount policy, package manager, signed manifest and filesystem permissions still determine what can change around the verified object.
Built-in signature support exists, but the official documentation notes that userspace verification can be more flexible and that enabling the kernel signature path increases attack surface. The right choice depends on the trust anchor and the update process. In either case, key rotation and revocation need a plan before an old signer remains trusted indefinitely.
Operationally, monitor verification failures separately from ordinary missing-file errors. EIO from this path is an integrity event, not a request to retry until the bytes look plausible. The service should fail closed for security-sensitive configuration, libraries or policy bundles, and it should preserve enough evidence to identify the expected digest and the file's update history.
Test the complete lifecycle: enable verification, read the file, alter storage outside the filesystem's protections when the test environment permits it, verify the failure, and then perform a controlled update that produces a new trusted digest. Tests that only check the ioctl return code do not exercise the read path.
fs-verity is valuable when the expected file digest is already part of the deployment contract. It is weak when treated as a label that means "verified" without a trusted reference. The security gain comes from joining a filesystem integrity check to a separate, reviewed source of truth.
