nosuid

What nosuid Means on a Mounted Filesystem

nosuid is not a content filter or a general hardening switch, it is a mount-time privilege boundary. By disabling set-user-ID and set-group-ID execution on that filesystem, it prevents binaries stored there from running with the file owner’s elevated privileges, even if those mode bits are present.

The practical effect is narrow but important: execution still works, but privilege inheritance does not. That makes it a good fit for removable media, shared volumes, and other mounts where the trust level of stored executables is lower than the host system that mounts them.

Why nosuid Exists in Linux Security

The control exists because file-based privilege elevation is a classic abuse path. If an attacker can place or influence a binary on a writable filesystem, set-user-ID or set-group-ID bits can turn a simple execution opportunity into elevated code execution. nosuid removes that specific path without otherwise changing normal file access.

In practice, the option is most useful where the mount is not fully trusted, such as USB devices, network shares, or transient application data volumes. It reduces the chance that an executable copied onto the filesystem can later be used to inherit unexpected effective credentials on the host.

Where nosuid Is Most Useful

Administrators usually apply nosuid to mounts that are meant to hold data, not trusted system binaries. Typical examples include removable storage, user-controlled shared directories, and some container or virtualization storage paths where the host wants to treat the filesystem as untrusted for privilege purposes.

The option is especially relevant when a system allows users or services to write to a mount and later execute from it. In that case, nosuid helps separate data storage from privilege-bearing execution, which is a common hardening pattern on multi-user systems.

Limitations and What nosuid Does Not Do

nosuid only neutralises the setuid and setgid bits at execution time. It does not stop code from running, it does not inspect the binary for malicious behaviour, and it does not address other ways of obtaining elevated access, such as kernel vulnerabilities, unsafe sudo policy, or overly permissive file ownership.

That means it should be treated as one layer in a broader mount and privilege strategy, not as a complete protection on its own. If the mount is still writable by an attacker, they may still be able to plant scripts, abuse interpreter paths, or exploit a separate trust boundary.

Risk and Threat Considerations

nosuid matters because executable content on untrusted or shared storage can become a privilege-escalation path if setuid or setgid bits are honoured. The main risk is not the mount option itself, but the loss of it, especially on media or shares that regular users can write to.

Failure mechanism: An attacker places or modifies a binary on a writable filesystem, then relies on set-user-ID or set-group-ID execution to inherit elevated privileges when that binary is launched.

Impact: The result can be unauthorized privilege escalation, credential or account abuse, and a much larger blast radius if the affected mount is widely accessible or routinely executed from.

Practitioner Guidance

What to watch for: Apply nosuid to mounts whose contents should not be treated as privilege-bearing executables, and review whether any workflow truly requires setuid or setgid execution from that location. If it does, that exception should be deliberate and tightly scoped.

Practitioner note: nosuid is most effective when paired with complementary mount restrictions and file ownership discipline. The goal is to make untrusted storage behave like data storage, not like a place where privilege can accidentally travel with a file.