A filesystem mounted at /srv/upload holds nothing but files uploaded by remote users. No program on it may ever be executed, any setuid bits on it must be ignored, and any device nodes found on it must be ignored. Select the THREE /etc/fstab options that enforce this.
LPIC-1 Exam 101-500, objective 104. Devices, Linux filesystems, filesystem hierarchy standard medium
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Choose 3.
Correct noexec
Correct. noexec makes the kernel refuse to execute binaries from that filesystem, so an uploaded program cannot be run in place.
Correct nosuid
Correct. nosuid makes the kernel ignore the setuid and setgid bits on files there, so a planted setuid-root binary confers no privilege.
Correct nodev
Correct. nodev makes the kernel ignore character and block special files on that filesystem, blocking a smuggled device node such as a writable copy of /dev/sda.
Not correct noatime
Wrong. noatime suppresses updates to the access timestamp. It is a performance option with no security effect.
Not correct sync
Wrong. sync makes writes go to the device immediately rather than through the cache. It changes durability and speed, not what may be run.
Not correct ro
Wrong here. A read-only filesystem still executes binaries perfectly well, so ro is no answer to 'nothing may be executed'; all it stops is writing — and an upload area exists to be written to.
Why
noexec, nosuid and nodev are the three hardening options applied to any filesystem holding untrusted content — upload areas, /tmp, removable media — and they are enforced by the kernel at the mount, not by permissions on the individual files. The mount option `user` already implies all three, which is why removable-media entries often look secure without saying so. Each has an opposite (exec, suid, dev) and the last matching option in the comma-separated list wins, so ordering matters when combined with `defaults`.
Where this comes from
- Cited
- manual page mount(8)
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 104 and space the ones you get wrong.
More questions on this objective
- A new disk /dev/sdb has no partition table at all. Which command writes an empty GPT partition table onto it without dropping you into an interactive editor? machine-checked
- You need the partition /dev/sdc1 on a USB stick to carry a FAT32 filesystem so that Windows machines can read and write it. Which command creates it? machine-checked
- You have just run `mkswap /dev/sdb2`. Which command makes the kernel start using that swap area immediately, without a reboot? machine-checked
- Why is it dangerous to run e2fsck against an ext4 filesystem that is currently mounted read-write? machine-checked
- On an ext4 filesystem at /dev/sda1 you want an automatic check to be forced after every 30 mounts. Which command sets that? machine-checked
- `df -h /var` reports the filesystem 100% full, but `du -sh /var` accounts for only about half that space. Nothing is hidden under a mount point. What is the most likely explanation? machine-checked
All questions on Devices, Linux filesystems, filesystem hierarchy standard