GSEC Linux Fundamentals Practice Question
A security analyst is reviewing a compromised Linux web server. The attacker escalated to root and then ran a script that unlinked the file /var/log/auth.log to hide their tracks. The analyst runs `lsof | grep auth.log` and sees the file is still open by the rsyslogd process, but `ls /var/log/auth.log` reports that the file does not exist. Which of the following best explains why the file content is still accessible through the open file descriptor?
⚠ Common exam trap
The trap here is assuming that deleting a file immediately frees its disk space and destroys its contents, when in fact an open file descriptor keeps the inode alive until the last handle is closed.
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 Linux kernel maintains the inode and data blocks until the last open file descriptor referencing the inode is closed, even after the directory entry is removed.
When a file is unlinked on Linux, the directory entry is removed but the inode persists as long as a process holds an open file descriptor. rsyslogd keeps auth.log open for writing, so the kernel cannot free the inode or data blocks. The analyst can recover the contents via /proc/<rsyslogd-pid>/fd/<descriptor>, even though the pathname no longer resolves. Restarting rsyslogd would close the descriptor and finally reclaim the inode.
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 Linux kernel maintains the inode and data blocks until the last open file descriptor referencing the inode is closed, even after the directory entry is removed.
Why this is correct
On Linux, unlinking a file only removes the directory entry (the name-to-inode link). The inode's link count drops, but the inode and its data blocks are not reclaimed while any process still holds an open file descriptor. The analyst can recover the content through /proc/<pid>/fd/<n>, which is why the data remains accessible to rsyslogd until it is restarted or closes the descriptor.
- ✗
The rsyslogd process has the file memory-mapped with mmap, so the page cache keeps a copy that ls can still resolve by inode lookup.
Why it's wrong here
A memory-mapped file would also keep the inode alive, but the scenario specifies the file was unlinked and lsof shows an open descriptor, not necessarily an mmap. More importantly, `ls /var/log/auth.log` fails because the directory entry is gone, regardless of page cache. mmap is not required for the observed behavior; a normal open() descriptor suffices.
- ✗
The file was moved to a hidden directory by the attacker, and lsof is resolving the path from the process's current working directory rather than the real inode.
Why it's wrong here
If the file had simply been moved, `ls /var/log/auth.log` would fail because the name changed, but the analyst could still find it with `find / -inum <inode>`. However, lsof resolves descriptors to the actual inode and path, not to the process's cwd. The scenario states the file was unlinked, so the inode remains alive only because it is still open, not because of cwd resolution.
- ✗
The ext4 filesystem journals file deletions, and lsof reads the journal to reconstruct the file contents until the journal is overwritten by subsequent writes.
Why it's wrong here
Journaling filesystems like ext4 journal metadata operations (including unlink), not file data, and lsof does not read the journal at all. lsof enumerates open file descriptors from /proc. Recovering file contents from a journal is not a feature of ext4 and would not explain why rsyslogd still holds the file open after the unlink.
Visual reference
About these practice questions
Courseiva writes every GSEC question from scratch — 351 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GSEC practice question is part of Courseiva's free GIAC 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 GSEC exam.