Devices, Filesystems and FHS →easyMultiple Choice

LPIC-1 Devices, Filesystems and FHS Practice Question

Exhibit

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=100m)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)

Refer to the exhibit. An administrator notices that /proc is mounted with 'noexec'. What is the impact of this mount option?

⚠ Common exam trap

Watch out — candidates often confuse 'noexec' with 'nosuid' or 'nodev', thinking it affects setuid binaries or device files, when in fact 'noexec' strictly controls whether binary executables can be run directly from the filesystem.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

No binaries can be executed directly from /proc.

The 'noexec' mount option prevents the direct execution of any binary files located on the mounted filesystem. Since /proc is a virtual filesystem that contains runtime system information and process data, mounting it with 'noexec' means that no binaries can be executed directly from /proc. This is a security measure to prevent malicious code from being run from procfs, as /proc should never contain executable programs in normal operation.

Answer analysis

Option-by-option breakdown

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

✗
Device files are not interpreted.
Why it's wrong here
noexec prevents execution of binary files; it does not stop the kernel from interpreting device nodes, which is governed by nodev. It is tempting because both options restrict filesystem behaviour, but nodev is the correct choice when the goal is blocking device file interpretation on a mount.
✗
Setuid programs do not work.
Why it's wrong here
The noexec option blocks execution of binaries stored on the filesystem; it does not disable the setuid permission bit, which governs privilege elevation when a program runs. It is tempting because setuid and execution are related, but noexec would be the right concern only when preventing users from running binaries on a mounted volume.
✓
No binaries can be executed directly from /proc.
Why this is correct
The noexec mount option blocks direct execution of any binary stored on that filesystem, so running an executable file located under /proc fails with a permission error. This satisfies the stem's constraint: /proc is mounted noexec, therefore no binaries can be executed directly from it.
✗
The filesystem cannot be written to.
Why it's wrong here
noexec prevents execution of binaries on the filesystem; it does not affect write access, which is governed by the ro option. It is tempting because noexec is often paired with ro on hardened mounts, but noexec alone is the correct answer when the requirement is blocking binary execution while permitting writes.

Go deeper

LPIC-1 Devices, Filesystems and FHS Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question