nodev

How nodev changes mount behavior

nodev tells the kernel to treat device nodes on a mounted filesystem as ordinary files rather than entry points to character or block devices. That means the filesystem can still hold and read regular data, but device files stored there will not function as live interfaces to hardware or kernel-managed device endpoints.

In practice, the option changes what happens when a process tries to open a device node from that mount. The path still resolves, but the mount is no longer trusted as a place where device files can be used to reach privileged kernel interfaces through the filesystem namespace.

Why nodev matters for filesystem hardening

nodev is one of the classic mount-time hardening options because device nodes can create an unintended bridge from ordinary file access to privileged system functions. On shared, temporary, or user-writable filesystems, disabling device interpretation reduces the chance that a crafted or copied device node becomes a usable attack path.

It is especially relevant where the filesystem content is not meant to manage hardware, such as removable media, application data mounts, scratch space, or directories that users may write to. In those cases, allowing device files to function often adds risk without operational value.

What nodev does not do

nodev is not a general sandbox and it does not stop every dangerous file from existing. A device node can still be present on disk as an inode, and regular files, directories, links, and metadata remain available. The option only suppresses the special meaning of device files on that mounted filesystem.

That distinction matters because administrators sometimes assume a mount option is equivalent to full containment. nodev reduces one class of exposure, but it does not replace permission management, filesystem ownership controls, or broader isolation measures.

Where administrators use nodev

nodev is typically applied to mounts where device access should never be necessary for normal workloads. It is commonly paired with other mount restrictions when the goal is to reduce the trust placed in filesystem contents and keep data-only mounts from behaving like a route to kernel devices.

Used carefully, it helps align mount behavior with the intended role of the filesystem. A data volume, application workspace, or temporary storage area should usually not be able to act as a transport for executable device interfaces.

Risk and Threat Considerations

Without nodev on a writable or loosely controlled mount, a malicious or careless user may be able to place device nodes on the filesystem and then use them to interact with kernel device interfaces the mount should not expose. That can widen the blast radius of a local compromise and turn a plain data path into a privileged access path.

Failure mechanism: The filesystem treats device nodes as functional special files, so a process that can reach the mount can potentially open a device endpoint instead of reading inert data. On shared or exposed mounts, that breaks the assumption that the directory tree is only storage, not a control surface for hardware or kernel interfaces.

Impact: The result can be unauthorized device access, unexpected interaction with sensitive system interfaces, and a larger opportunity for local privilege abuse or containment bypass. The exact consequence depends on the device and permissions involved, but the security boundary is clearly weaker when device interpretation is allowed.

Practitioner Guidance

Common misunderstanding: nodev is often mistaken for a broad security control, when it only disables device node interpretation on the specific mount. Treat it as one hardening measure in a mount policy, not as a substitute for least privilege, ownership control, or isolation of untrusted content.

Governance implication: Administrators should standardize where nodev is required and verify that mounts intended for data only are configured accordingly. The key question is whether the filesystem ever needs to host functional device nodes; if not, nodev should usually be part of the baseline mount profile.