LFCS Essential Commands Practice Question
A security audit reveals that a sensitive file '/etc/shadow' has been modified. The file's permissions are set to 600 and owned by root. However, the audit logs show that a service account 'webapp' was able to read the file. The 'webapp' user is not in the root group. Which of the following is the most likely method the 'webapp' user used to read the file?
⚠ Common exam trap
Many exam-takers assume traditional Unix permissions (owner/group/other) are the only way to control access, overlooking that ACLs can grant specific users read permission even when the file's mode appears restrictive (e.g., 600).
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
✓
The file has an Access Control List (ACL) granting read permission to 'webapp'.
An Access Control List (ACL) can grant specific permissions to a user or group beyond the traditional Unix permission model. Even though the file's mode is 600 (owner read/write only) and owned by root, a setfacl command could have added an ACL entry (e.g., 'u:webapp:r') that explicitly allows the 'webapp' user to read /etc/shadow. This is a common method to give a service account access to a sensitive file without changing its ownership or group membership.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The file is a hard link to another file that is readable by 'webapp'.
Why it's wrong here
Hard links share the same inode and permissions; if the original is 600, the link is also 600.
- ✗
The 'webapp' user exploited a SUID binary that reads the file.
Why it's wrong here
Exploiting a SUID binary, while allowing a non-root user to execute code with root privileges, is less direct for simply reading a file with `600` permissions. This method relies on a vulnerability within a specific SUID program that `webapp` could exploit to read arbitrary files, rather than a direct permission grant. SUID is designed for specific, controlled privilege escalation for tasks like `passwd`, not general file access. It is tempting because SUID binaries do run as root, and a vulnerable one could indeed be used to access `/etc/shadow`. However, other mechanisms more directly grant a user read access to a file without requiring a separate program exploit.
- ✓
The file has an Access Control List (ACL) granting read permission to 'webapp'.
Why this is correct
ACLs override base permissions and can grant access to specific users.
- ✗
The 'webapp' user used 'sudo' to read the file as root.
Why it's wrong here
Sudo usage would appear in logs and require configuration; less likely without evidence.
Visual reference
Go deeper
Related to this question
About these practice questions
This LFCS question is part of Courseiva's 507-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.