fanotify permission events can block file access, but only while the listener answers
fanotify can notify a process when another process opens a file. With permission events such as FAN_OPEN_PERM, the kernel waits for the listener to approve or deny the operation. That makes fanotify useful for malware controls, file-integrity products, and data-loss prevention. It also makes the listener part of the filesystem availability path.
A permission event is a blocking decision
The fanotify manual describes permission events as operations that require a response from the program that initialized the notification group. The program reads an event and writes a decision to the fanotify file descriptor. The decision happens before the file is opened. This is different from an audit event that reports access after the fact.
Permission events are not merged into one queue entry. A busy host can therefore create a large number of individual decisions. Design the listener with bounded queues, explicit overload behavior, and monitoring. If the listener is slow, applications may wait. If it crashes, administrators need to know whether access resumes, is denied, or remains pending. Test that behavior in a lab before enabling enforcement on production mounts.
Scope the mark before the decision
An enforcement profile should identify the mount, the object mask, and the processes whose events matter. Marking an entire root filesystem captures the package manager, log rotation, backup agents, and the monitoring process itself. Exclude the listener's own events where the API permits it, and use separate groups for visibility and blocking. A group that only reports events should not inherit the failure mode of a group that decides them.
The capability needed to initialize fanotify is privileged. Give the listener only the capability and namespace it needs. Run it as a dedicated service, keep its configuration root-owned, and do not expose a control socket to unprivileged users. If the product offers an allowlist file, that file is security policy and should be versioned and reviewed.
Plan for unavailable storage
A file-access control can become an availability incident when the policy server or local daemon is unavailable. Use a local decision path with a short timeout and a documented fallback. Do not assume that a closed file descriptor automatically yields the safest outcome in every kernel version. Test the exact kernel and distribution, record the result, and choose a behavior that matches the risk of the protected data.
Monitor the event rate, decision latency, queue length, dropped events, listener restarts, and denied operations. A sudden rise in FAN_OPEN_PERM events can indicate a scan loop or a change in the mount scope. Send the listener's health to the same monitoring system as the protected service, and alert before the queue becomes full.
Verify both allow and deny
Use a benign file and an application that should be allowed. Confirm that the open succeeds and that the listener records the decision. Use a test file that the policy should block and confirm that the application sees a refusal. Restart the listener during a test and observe whether the service recovers without manual cleanup. Repeat the test after a kernel or product update.
The strongest deployment separates visibility from enforcement. Start with a report-only group, build a map of normal access, then add a narrow permission policy. That sequence reduces the chance that a noisy or unavailable listener becomes an unplanned outage.
