`ls -l /srv/report.csv` shows `lrwxrwxrwx 1 root root 19 ... /srv/report.csv -> /data/q3/report.csv`, and the file at the other end is `-rw-r----- 1 root staff`. A user who is neither root nor a member of staff tries to read /srv/report.csv. What decides whether the read is allowed?
LPIC-1 Exam 101-500, objective 104. Devices, Linux filesystems, filesystem hierarchy standard hard
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
Correct The permissions of the target file, /data/q3/report.csv. The link's own mode is never consulted.
Correct. Opening a symbolic link resolves it and then applies the target's permission bits, so this user is refused by the target's mode of 640.
Not correct The rwxrwxrwx bits on the link, which grant read and write to everyone.
Wrong, and this is the trap the listing sets. On Linux the permissions of an ordinary symbolic link are not used in any operation; they are always 0777 and cannot be changed, which is why every symbolic link on the system looks like this.
Not correct The stricter of the two modes, because the kernel checks the link and then the target.
Wrong. There is no combination step. The link's mode takes no part in the decision at all, so there is nothing to intersect the target's mode with.
Not correct The link's ownership, root:root, because the kernel tests who owns the link before following it.
Wrong. A symbolic link's ownership matters in two narrow cases — removing or renaming it in a directory with the sticky bit set, and the protected_symlinks hardening — and in neither of them does it grant access to the target.
Why
A symbolic link's mode is decoration. Every one of them is displayed as lrwxrwxrwx because the permissions of an ordinary symbolic link are always 0777, are used in no operation, and cannot be changed. What governs access is the resolution of the path: search permission on each directory traversed, then the permission bits of the file the link finally names. The corollary catches people out — chmod applied to a symbolic link follows it and changes the mode of the target instead, so `chmod 600` on a link is a change to the file at the other end, not to the link.
Where this comes from
- Cited
- manual page symlink(7)
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