EX200 Create and configure file systems Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  nosuid

  Why this is correct

  Mounting a filesystem with nosuid disables the setuid and setgid bits on all executable files within it, so a binary cannot temporarily assume the UID or GID of its file owner. This is critical for partitions like /tmp that are writable by unprivileged users, because a setuid root binary created there could otherwise be exploited for privilege escalation. Administrators commonly include nosuid when mounting removable media or network shares to prevent untrusted binaries from attaining local higher privileges.

• ✓

  nodev

  Why this is correct

  The nodev mount option forbids the kernel from interpreting any block or character device nodes contained in that filesystem as device files, so opening them cannot access underlying hardware. Without nodev, a user with write access to a mounted partition could create a device node that points to a raw disk or /dev/mem, effectively bypassing standard permission checks. This is why nodev is always used on world-writable directories and on removable filesystems where the device node table is not trusted.

• ✗

  suid

  Why it's wrong here

  The suid mount option explicitly permits setuid and setgid executables to run with the file owner's effective privileges, which is the default behavior once a filesystem is mounted without the nosuid flag. Listing suid as a security hardening option is incorrect because it re-enables a known privilege-escalation vector, especially on writable filesystems. In practice, a secure setup would reject suid and instead apply nosuid, so suid is not one of the three commonly used safe mount options.

• ✗

  defaults

  Why it's wrong here

  The 'defaults' mount option is actually a shorthand for rw, suid, dev, exec, auto, nouser, and async, meaning it permits setuid binaries and device nodes just like a standard local mount. It is not a security-focused option; it simply applies the filesystem's built-in defaults, which are permissive and leave the partition open to device-node and setuid attacks. Choosing 'defaults' as a hardening measure is wrong because it does nothing to restrict execution, device access, or privilege escalation, and it actually enables the very behaviors that nosuid, nodev, and noexec are designed to block.

• ✓

  noexec

  Why this is correct

  Mounting with noexec prevents the kernel from executing any binary file directly from that filesystem, as all execve() calls on those inodes return EACCES. It is a common defense on /tmp and /var/tmp to stop an attacker who has achieved write access from running downloaded malware or compiled payloads from that location. Note, however, that noexec does not block interpreted code like 'sh script.sh' because the interpreter itself lives on a different executable filesystem and merely reads the script as input, so noexec is a mitigation rather than a complete code-execution barrier.

Go deeper

Related to this question