Cyber Security Quiz: User And File System Privileges
10 questions · exam conditions
0:00
User And File System PrivilegesQuestion 1 of 10

On a Unix-like file system, /work/budget.csv and /archive/budget-link.csv are hard links to the same regular file. An authorized owner runs chmod 0600 /work/budget.csv and then deletes /work/budget.csv. No process has the file open.

What is the resulting state of /archive/budget-link.csv?

It is deleted because removing either hard link removes the underlying file.
It remains accessible under that name but retains its previous mode.
It remains accessible under that name and reflects mode 0600.
It becomes a dangling link because the original pathname no longer exists.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: User And File System Privileges

Practice User And File System Privileges in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on User And File System Privileges, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

On a Unix-like file system, /work/budget.csv and /archive/budget-link.csv are hard links to the same regular file. An authorized owner runs chmod 0600 /work/budget.csv and then deletes /work/budget.csv. No process has the file open.

What is the resulting state of /archive/budget-link.csv?

  1. It is deleted because removing either hard link removes the underlying file.
  2. It remains accessible under that name but retains its previous mode.
  3. It remains accessible under that name and reflects mode 0600. (correct answer)
  4. It becomes a dangling link because the original pathname no longer exists.
Explanation: Whenever you see a question involving hard links on Unix-like systems, anchor your thinking to one core idea: a hard link is not a pointer to another file — it is the file. Every hard link is a direct directory entry referencing the same underlying inode, which stores the file's actual data and metadata, including permissions. When the owner runs chmod 0600 /work/budget.csv, the permission bits are written to the shared inode — not to any specific pathname. Since /archive/budget-link.csv references that same inode, it immediately reflects the 0600 mode without any additional action. Then, when /work/budget.csv is deleted, the kernel simply decrements the inode's link count from 2 to 1. The inode and its data persist as long as at least one hard link remains. Because /archive/budget-link.csv still exists, the file survives and continues to show 0600. This makes C the correct answer. A is wrong because deleting one hard link never removes the underlying file — it only removes that directory entry and decrements the link count. The file is only truly deleted when the link count reaches zero. B traps you into thinking permissions are stored per-pathname rather than per-inode; since both links share one inode, the mode change is immediately visible through all names — not just the one chmod was called on. D describes a symbolic (soft) link, not a hard link. Dangling links occur when a symlink's target is deleted, leaving the symlink pointing nowhere — hard links have no such vulnerability. Remember the mnemonic: hard links share the inode, symlinks share a path. Permission questions on hard links almost always hinge on understanding that metadata lives on the inode, not the directory entry.

Question 2

The directory /projects/app is owned by root:developers and has mode 2775, so its set-group-ID bit is enabled. Priya's primary group is staff, and she is also a member of developers. She creates a regular file there using requested mode 0666 while her umask is 0002.

Which ownership and mode should the new file normally have?

  1. Owner priya, group developers, and mode 0664 (correct answer)
  2. Owner priya, group staff, and mode 0664
  3. Owner root, group developers, and mode 0664
  4. Owner priya, group developers, and mode 0675
Explanation: When a directory has the set-group-ID (SGID) bit set (the "2" in 2775), any new file created inside it automatically inherits the directory's group ownership — not the creator's primary group. This is the central mechanic being tested here. So when Priya creates a file in /projects/app, the file's owner is priya (always the creating user), and the group becomes developers (inherited from the directory's SGID), not her primary group staff. That confirms A is correct — but you still need to verify the mode. The requested mode is 0666 (rw-rw-rw-). Applying Priya's umask of 0002 clears the bits in 0002, meaning write permission is removed from the "other" category: 0666 & ~0002 = 0664 (rw-rw-r--). So the final mode is 0664, and ownership is priya:developers. Answer A is correct. B is wrong because it assigns group staff, which would only happen without SGID — the whole point of SGID on a directory is to override the creator's primary group. C is wrong because file ownership always goes to the creating user (priya), never inherited from the directory owner (root). Root owns the directory, not new files within it. D is wrong because the mode 0675 doesn't follow from applying the umask correctly — it appears to confuse the SGID bit's effect on modes (SGID on a file affects execution behavior, not the numeric mode produced during creation). Study tip: Always separate the two inheritance questions — group comes from SGID, mode comes from requested & ~umask. Keep those calculations independent.

Question 3

On a Unix-like system that honors set-user-ID executables, /usr/local/bin/collector is a binary owned by root with mode 4755. User sam executes it normally. No mount option, sandbox, or process setting suppresses set-user-ID behavior.

Which description best represents the process while the program is running?

  1. Its real and effective user IDs remain Sam's, but its group privileges become root's.
  2. Its real and effective user IDs both become root's until the process exits.
  3. Its real user ID is Sam's, while its effective user ID is root's for permission checks. (correct answer)
  4. Its real user ID becomes root's, while its effective user ID remains Sam's.
Explanation: When a Unix-like system executes a set-user-ID (SUID) binary, it distinguishes between who you are and what privileges you're temporarily granted. These two concepts map to two separate kernel-maintained values: the real user ID (RUID) and the effective user ID (EUID). The RUID tracks who actually launched the process; the EUID is what the kernel checks when making permission decisions like file access or system calls. When sam runs /usr/local/bin/collector — owned by root with mode 4755 (the leading 4 signals the SUID bit) — the kernel sets the EUID to the file's owner (root) while leaving the RUID as sam. This is exactly what answer C describes, making it correct. Sam remains accountable as the real user, but the process gains root's permissions for every access check during execution. Answer A is wrong because SUID affects the user IDs, not group IDs. Group privilege escalation would require the SGID bit (mode 2xxx), not SUID. Answer B is wrong because the real user ID never changes to root — sam always remains the RUID. Conflating RUID with EUID is a very common misconception this question is designed to catch. Answer D reverses the logic entirely: the RUID stays as sam and the EUID becomes root, not the other way around. A useful memory anchor: Real = who ran it, Effective = what it can do. SUID only flips the Effective ID to the file owner. On any exam question about SUID, immediately ask yourself which of these two IDs changes — and the answer is always the effective one.

Question 4

A Linux file has the following POSIX ACL entries: user::rw-, user:bob:rwx, group::r--, group:audit:rw-, mask::r-x, and other::---. Bob is also a member of the audit group, but he does not own the file.

What effective access does Bob receive from this ACL?

  1. Read and write, because the system accumulates permissions from all of Bob's matching ACL entries before applying the mask
  2. Read, write, and execute, because a named-user entry takes effect without being reduced by the mask
  3. Read only, because the system intersects Bob's named-user entry with his matching group entry
  4. Read and execute, because the named-user entry user:bob:rwx is constrained by the ACL mask r-x (correct answer)
Explanation: When working with POSIX ACLs, the most important concept to internalize is the mask. The mask acts as a ceiling that limits the effective permissions of all named users, named groups, and the owning group — think of it as a bitwise AND applied after the system selects which entry governs access. Here's how to work through Bob's situation. Because Bob is a non-owning named user, the system immediately selects his named-user entry (user:bob:rwx) — it stops looking and does not combine it with any group entries. However, that entry still passes through the mask (r-x). Intersecting rwx with r-x yields r-x, meaning Bob's effective permissions are read and execute. That confirms D is correct. Choice A is wrong because POSIX ACLs do not accumulate entries. The system picks the single best-matching entry — the named-user entry wins and group entries are ignored entirely. Choice B contains a dangerous half-truth: named-user entries are selected first, but they are absolutely subject to the mask. The mask applies to every entry except user:: (file owner) and other::. Choice C describes a fictional intersection between the named-user and group entries, which is not how ACL evaluation works — once a named-user entry matches, group entries are irrelevant to Bob's access. A reliable study tip: memorize the ACL evaluation order — (1) file owner, (2) named user, (3) owning group + named groups, (4) other — and remember that the mask constrains everything in steps 2 and 3. If you apply both rules together, POSIX ACL questions become straightforward.

Question 5

A shared Linux directory has mode 1777 and is owned by root. Inside it, alex owns report.txt. An access control list on the file grants user blair read and write access to its contents. Blair is not the directory owner and has no administrative privilege.

Which statement best describes Blair's access?

  1. Blair can modify and delete the file because the file ACL grants write access.
  2. Blair can modify the file's contents but cannot delete or rename its directory entry. (correct answer)
  3. Blair can delete the file but cannot modify it because the directory is world-writable.
  4. Blair cannot modify or delete the file because the sticky bit overrides its ACL.
Explanation: When Linux file permissions and ACLs appear together, you need to think about two separate layers of control: the directory's permissions govern directory operations (creating, deleting, renaming entries), while the file's own permissions and ACLs govern operations on the file's contents. These layers are independent. Here, the directory has mode 1777. The 1 is the sticky bit, and 777 means everyone has read, write, and execute on the directory. Normally, world-writable directories would let anyone delete any file inside. The sticky bit changes that rule: even in a world-writable directory, you can only delete or rename a file if you own it or own the directory. Blair owns neither the file (alex does) nor the directory (root does), so Blair cannot delete or rename report.txt regardless of what the ACL says. However, the file's ACL explicitly grants Blair read and write access to the file's contents, so Blair can open the file and modify what's inside. That makes B correct. Choice A is wrong because write access on a file's ACL does not confer the ability to delete its directory entry — deletion is a directory operation, controlled by directory permissions and the sticky bit. Choice C has the causality backwards: the directory is world-writable, but the sticky bit is precisely what prevents unprivileged deletion, not enables it. Choice D overstates the sticky bit's scope — it restricts deletion of directory entries, but it does not touch or override ACLs on file contents. A reliable mental model: the sticky bit is a directory-level guard on unlinking files; ACLs are file-level guards on reading and writing data. Keep those two planes separate on exam day.

Question 6

On a Linux system, plans.txt is owned by user maya and group design. Its mode is 0460, giving the owner read permission, the group read and write permissions, and others no permissions. Maya is also a member of the design group.

What happens when Maya attempts to modify plans.txt through a process running with her normal credentials?

  1. The modification succeeds because her design group membership grants write permission.
  2. The modification fails because the owner permission class applies and does not grant write permission. (correct answer)
  3. The modification fails because a file must grant write permission to both owner and group.
  4. The modification succeeds because the system combines all permission classes that match her identity.
Explanation: When Linux checks file permissions, it doesn't combine or average across permission classes — it applies exactly one class based on your relationship to the file, evaluated in strict priority order: owner first, then group, then others. This single-class rule is the key concept being tested here. Maya is the owner of plans.txt, so the system immediately applies the owner permission class (the first octet, 4 in 0460), which grants only read (r--). The evaluation stops there — Linux never checks the group class for Maya, even though she's a member of design and the group class would grant her write access. Her attempt to modify the file fails because the owner class doesn't include write permission. That makes B correct. A is the classic trap this question is designed for. It seems intuitive that group membership should help Maya, but Linux doesn't layer permissions — once it determines you're the owner, only the owner class counts. Her group membership is simply irrelevant to this decision. C describes a rule that doesn't exist. Linux has no requirement that both owner and group grant write permission for a write to succeed. That's an invented constraint. D is wrong for the same reason as A — Linux never "combines" or unions the matching permission classes. Only one class applies, determined by the identity hierarchy. The study tip here: always think of Linux permission checks as a strict waterfall, not a union. Ask yourself, "Which single class applies?" and evaluate only that class. Many exam questions hinge precisely on this owner-first, single-class evaluation rule.

Question 7

A Linux service creates a regular file by requesting mode 0666. The service is running with a umask of 0027, and it does not subsequently call chmod or apply an access control list.

What mode will the newly created file normally receive?

  1. 0640, granting owner read/write and group read permissions (correct answer)
  2. 0660, granting owner and group read/write permissions
  3. 0627, subtracting the umask digits directly from the request
  4. 0750, adding execute permissions implied by the directory access
Explanation: When a Linux process creates a file, the kernel doesn't simply assign the requested permissions — it masks out certain bits first. The umask defines which permission bits should be removed from any newly created file. The formula is: final mode=requested mode&∼(umask)\text{final mode} = \text{requested mode} \mathbin{\&} \sim(\text{umask}) In other words, any bit that is set in the umask gets cleared from the result. With a requested mode of 0666 and a umask of 0027, you compute: 0666&∼(0027)=0666&0750=06400666 \mathbin{\&} \sim(0027) = 0666 \mathbin{\&} 0750 = 0640 Breaking it down: the umask 0027 removes write permission from the group (the 2 bit) and all permissions from others (the 7 bits), leaving owner read/write (6), group read only (4), and no other permissions (0). That is answer A, the correct choice. Answer B (0660) is wrong because it preserves the group write bit, which the umask specifically strips out. Answer C (0627) reflects a common misconception — you do not subtract umask digits arithmetically from the requested mode. That would give a wrong result whenever borrowing would be involved, and it misrepresents how bitwise masking works. Answer D (0750) is a fabrication; the kernel never adds execute bits during file creation, and directory permissions don't bleed into new file modes. A useful memory anchor: think of the umask as a "permission eraser." Whatever bits are set in the umask get erased from the request — no subtraction, no addition, just a bitwise AND with the complement.

Question 8

A Linux directory named /shared/drop has mode 0733, is owned by root, and does not have the sticky bit set. User Noor has execute permission on every parent directory. Inside /shared/drop, another user owns old.log, whose mode is 0444.

Which outcome is most likely when Noor attempts to delete old.log?

  1. Deletion succeeds because Noor has write and execute permissions on the containing directory. (correct answer)
  2. Deletion fails because Noor does not have write permission on the file itself.
  3. Deletion fails because Noor cannot read the directory's list of filenames.
  4. Deletion succeeds only if Noor first changes the file's read-only mode.
Explanation: When dealing with file deletion on Linux, the key insight is this: deleting a file is an operation on the directory, not the file itself. To remove a filename entry from a directory, you need write (w) and execute (x) permissions on the containing directory — the file's own permissions are irrelevant to deletion. Here, /shared/drop has mode 0733, meaning the owner (root) gets rwx, and both group and others get -wx. Noor, as another user, falls into the "others" category and therefore has write and execute on the directory. That's exactly what's needed to unlink old.log from that directory. So A is correct — deletion succeeds purely based on directory permissions. B reflects one of the most common misconceptions in Linux permissions: that you need write access to a file to delete it. You don't. Write permission on a file only controls whether you can modify its contents, not whether you can remove its directory entry. C is wrong because read permission on a directory controls listing its contents (e.g., ls). Noor lacks read (r) on /shared/drop, so she can't list files — but she already knows the filename old.log, and execute permission alone is enough to access known entries. No read permission is needed for deletion. D is wrong because changing the file's mode would be irrelevant — file permissions don't gate deletion. Noor also couldn't change old.log's mode anyway, since she doesn't own it. Study tip: Remember the mantra — delete = write + execute on the parent directory, period. The sticky bit (+t) is the one exception that adds ownership checks, so always check for it on shared directories.

Question 9

On a Windows system, an administrator moves forecast.docx from a restricted Finance folder to a broadly accessible Public folder on the same NTFS volume. The file has explicit NTFS permissions, and the administrator does not manually alter its access control list.

What is the most likely permissions outcome immediately after the move?

  1. The file loses all permissions except full control for the administrator who moved it.
  2. The file replaces its permissions with those inherited from the Public destination folder.
  3. The file combines every Finance permission with every inherited Public permission.
  4. The file retains its existing permissions because it was moved within the same NTFS volume. (correct answer)
Explanation: When you see questions about NTFS file permissions and file operations, the key distinction to focus on is whether the file is being moved or copied, and whether the operation crosses volume boundaries. Within the same NTFS volume, a move operation is not a true data transfer — Windows simply updates the file's directory entry to point to the new location. Because the file's underlying metadata, including its Access Control List (ACL), travels with it untouched, the explicit permissions set on forecast.docx survive the move intact. This makes D correct: the file retains its existing explicit permissions because no new object was created. A is wrong because NTFS moves don't strip permissions down to administrator-only full control — that would be a serious security flaw and doesn't reflect how Windows handles ACLs during same-volume moves. B describes what happens during a cross-volume move (which behaves like a copy-then-delete), or when a file has only inherited permissions with no explicit entries. Since this file has explicit permissions, inheritance from the Public folder does not override them. C reflects a common misconception that permissions "merge" during a move. NTFS never automatically combines source and destination permission sets — that kind of ACL blending doesn't exist as a default behavior. A reliable study tip: remember the phrase "same volume = same ACL." When a file moves within one NTFS volume, think of it as sliding across a shelf — the label doesn't change. Only cross-volume moves or manual resets trigger permission inheritance from the destination.

Question 10

A Windows user accesses a folder through an SMB share. The share permission grants the user Read, while the NTFS permission on the folder grants Modify. No deny entries or other applicable permissions exist.

Which action should the user be able to perform through the network share?

  1. Read existing files but not modify or delete them through the share (correct answer)
  2. Read and modify files because the more permissive NTFS permission prevails
  3. Modify and delete files because applicable share and NTFS permissions are combined
  4. Change folder permissions but not file contents because NTFS controls authorization
Explanation: Whenever you see a question involving both share permissions and NTFS permissions on a Windows system, remember the golden rule: the most restrictive permission wins. These two permission systems work as independent filters — a user's effective access through the network is whichever layer is more restrictive, not the combination or the more generous one. Here's how to apply that rule: the share permission grants Read, and the NTFS permission grants Modify. Think of these as two security checkpoints. Even though NTFS would allow the user to modify files locally, the share permission caps network access at Read. The user cannot exceed what the share allows when connecting remotely, making A the correct answer — the user can only read files through the network share. Choice B gets the logic exactly backwards. The more permissive permission does not prevail; the more restrictive one does. This is the most common trap on permission-related questions, so watch for it. Choice C introduces a misconception that permissions are combined additively — as if Read + Modify = Modify. That's not how Windows permission layering works; the layers don't stack upward, they cap downward. Choice D is simply fabricated logic — NTFS permissions do not grant the ability to change folder permissions based on share access, and the scenario gives no indication of ownership or special permissions that would allow ACL modification. A handy memory anchor: think of share and NTFS permissions as two funnels stacked on top of each other — water (access) can only flow through the narrowest point. On exam questions, always identify both permission levels, then pick whichever is more restrictive.