Cyber Security Quiz: Linux Permissions And Sudo
10 questions · exam conditions
0:00
Linux Permissions And SudoQuestion 1 of 10

A user who is permitted to run commands through sudo enters:

sudo echo enabled > /etc/app.conf

The file is root-owned and is not writable by the user. The shell reports Permission denied.

Which explanation and correction are most accurate?

The user's shell performs the redirection; piping the text to sudo tee /etc/app.conf elevates the write.
sudo elevates the whole line, but echo cannot write files because it is commonly a shell built-in.
The root process performs the redirection, but the file's owner-write bit still prevents root from opening it.
sudo cannot modify configuration files; the user must instead log in directly as the root account.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Linux Permissions And Sudo

Practice Linux Permissions And Sudo 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 Linux Permissions And Sudo, 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

A user who is permitted to run commands through sudo enters:

sudo echo enabled > /etc/app.conf

The file is root-owned and is not writable by the user. The shell reports Permission denied.

Which explanation and correction are most accurate?

  1. The user's shell performs the redirection; piping the text to sudo tee /etc/app.conf elevates the write. (correct answer)
  2. sudo elevates the whole line, but echo cannot write files because it is commonly a shell built-in.
  3. The root process performs the redirection, but the file's owner-write bit still prevents root from opening it.
  4. sudo cannot modify configuration files; the user must instead log in directly as the root account.
Explanation: When you see a question involving sudo and file redirection, the critical concept to understand is who performs each part of the command — because the shell processes operators like > before sudo ever runs. Here's what actually happens: when your shell sees sudo echo enabled > /etc/app.conf, it parses the redirection first, attempting to open /etc/app.conf for writing as your unprivileged user. Only after that does it hand echo enabled off to sudo. Since your user lacks write permission on the root-owned file, the shell fails immediately — sudo never even gets a chance to elevate anything. The fix is sudo tee /etc/app.conf <<< "enabled" or echo enabled | sudo tee /etc/app.conf, which runs tee — the process doing the writing — under elevated privileges. This makes A correct. B is wrong because the issue isn't that echo is a shell built-in; the problem is purely about who opens the file for writing, which is always the shell handling >. C contains a fundamental error: root bypasses standard discretionary access control entirely — no owner-write bit can stop root from opening a file. The premise is false. D is simply wrong policy and bad security advice; sudo is specifically designed to elevate individual commands without requiring a full root login session. The study tip here: whenever you see redirection (>, >>) in a sudo command, ask yourself — who is the shell? The shell is always you, not root, unless you explicitly launch a root shell. That single question will guide you to the right answer every time.

Question 2

Elena is authorized through sudo to run /usr/bin/journalctl and has just authenticated successfully. While the sudo authentication timestamp is still valid, she enters sudo /bin/cat /etc/shadow. No rule authorizes that command.

What is the expected result?

  1. The command succeeds because a valid sudo timestamp temporarily authorizes every root command.
  2. The command succeeds because authenticating proves Elena is entitled to use the root account.
  3. The command is denied because cached authentication does not expand the commands authorized by policy. (correct answer)
  4. The command runs without elevation because sudo falls back to Elena's normal permissions.
Explanation: When you see a question about sudo and privilege escalation, focus on the distinction between authentication and authorization — they are separate concepts that sudo enforces independently. Sudo uses a two-layer model. First, it checks its policy (typically /etc/sudoers) to determine which specific commands a user is authorized to run with elevated privileges. Second, it handles authentication via a timestamp cache to avoid prompting for a password on every command within a session window. The critical point is that the timestamp cache only skips the password prompt — it does not alter or expand the policy rules themselves. Elena is authorized to run /usr/bin/journalctl, and that is all. When she attempts sudo /bin/cat /etc/shadow, sudo checks the policy, finds no matching rule, and denies the request regardless of whether her authentication timestamp is still valid. That makes C correct. A is wrong because it conflates the authentication cache with a blanket root authorization. The timestamp means "we already verified your identity recently," not "you may now run anything as root." B commits a similar error — successful authentication proves who you are, never what you're allowed to do. Identity verification and access rights are fundamentally different security primitives. D is wrong because sudo does not silently fall back to the user's unprivileged permissions when a rule is missing; it explicitly denies the command and logs the violation. A useful rule of thumb: on any exam question involving sudo, ask yourself two separate questions — "Is this user authenticated?" and "Is this specific command authorized?" Both must be true for the command to succeed.

Question 3

Sam knows that /src/data.txt exists. The source directory /src has mode 0711, and data.txt has mode 0644. The destination directory /dest has mode 0733, and /dest/copy.txt does not yet exist. Sam is treated as an other user for all three objects. All parent directories are traversable, and no ACLs apply.

What happens when Sam runs cp /src/data.txt /dest/copy.txt?

  1. The copy fails because the source file lacks execute permission for Sam's permission class.
  2. The copy fails because Sam lacks read permission on /src and therefore cannot use a known filename.
  3. The copy fails because Sam lacks read permission on /dest, even though it grants write and execute.
  4. The copy succeeds because Sam can traverse the source, read the file, and write within the destination. (correct answer)
Explanation: When working through Unix file permission questions, think operationally: break the command into discrete steps and ask what permission each step requires on each object. For cp /src/data.txt /dest/copy.txt, Sam needs three things: traverse /src to reach the file, read data.txt, and write a new file into /dest. Sam is treated as "other" throughout. /src has mode 0711, so other has execute (traverse) — no read needed to access a file by known path. data.txt has mode 0644, so other has read — Sam can read its contents. /dest has mode 0733, so other has write and execute — write lets Sam create a new file, and execute lets Sam access the directory. Since /dest/copy.txt doesn't yet exist, no permissions on that file are checked. Every step clears, so D is correct: the copy succeeds. Choice A is wrong because reading a file requires read permission on the file itself, not execute. Execute on a file means running it as a program — it's irrelevant to cp. Choice B contains a subtle but important misconception: you do not need read permission on a directory to access a file inside it by name. Read permission on a directory allows you to list its contents (ls). Since Sam already knows the filename, only execute (traverse) permission on /src is required, and 0711 provides exactly that. Choice C applies the same misconception to /dest — read on a directory enables listing, not writing. Write plus execute is fully sufficient to create a new file. Remember this pattern: directory execute = traverse, directory read = list, directory write = create/delete files. Exams frequently exploit the read-vs-execute confusion on directories — always ask what operation you're actually performing.

Question 4

An operator is authorized to run sudo /usr/bin/touch /root/a. The /root directory has mode 0700. From an ordinary shell, the operator enters:

sudo /usr/bin/touch /root/a && /usr/bin/touch /root/b

Assuming /root/a does not already exist, which outcome is expected?

  1. Both files are created because sudo elevates the complete conditional command line.
  2. Only /root/a is created because the shell runs the second touch without sudo elevation. (correct answer)
  3. Only /root/b is created because && discards sudo elevation from the first command.
  4. Neither file is created because sudo cannot be used as part of an && command list.
Explanation: When you see a question involving sudo and shell operators like &&, ask yourself: what does the shell actually parse and execute, and at what privilege level? The key insight is that sudo elevates only the single command you pass to it — not the entire command line you typed. Here's what happens step by step. Your shell parses sudo /usr/bin/touch /root/a && /usr/bin/touch /root/b as two separate commands joined by &&. The shell runs sudo /usr/bin/touch /root/a with elevated privileges, which succeeds and creates /root/a. Because that first command exited successfully, && triggers the second command — but the shell runs /usr/bin/touch /root/b under your ordinary user privileges. Since /root has mode 0700 (owner-only access) and you're not root, the second touch is denied, and /root/b is never created. That makes B the correct answer. A is wrong because sudo does not "bubble up" to cover the entire shell command line — it is scoped strictly to the argument you give it. C inverts the logic entirely; && does not strip elevation from anything, and it's the second command that fails, not the first. D is wrong because sudo works perfectly fine as part of a && list — the first command succeeds without issue. As a study tip, remember: sudo elevates one command, not one line. Shell operators (&&, ||, ;) are interpreted by your unprivileged shell, so anything after them runs at your normal permission level unless you explicitly prepend sudo again.

Question 5

An administrator runs the following commands on a regular file:

chmod 640 audit.log

chmod g+x,o+r audit.log

What permission mode does audit.log have after both commands complete?

  1. 0654, displayed as -rw-r-xr-- (correct answer)
  2. 0644, displayed as -rw-r--r--
  3. 0674, displayed as -rw-rwxr--
  4. 0754, displayed as -rwxr-xr--
Explanation: When working with Linux file permissions, you need to track two things: the starting state and how each subsequent chmod command modifies it — either symbolically or absolutely. The first command, chmod 640, sets permissions absolutely: owner gets read+write (6), group gets read-only (4), others get nothing (0). In symbolic notation, that's -rw-r-----. The second command, chmod g+x,o+r, is symbolic — it adds permissions without removing existing ones. Breaking it down: g+x adds execute to the group bits, and o+r adds read to the others bits. Applying these to the current state:
  • Owner: stays rw- → 6
  • Group: r-- becomes r-x → 5
  • Others: --- becomes r-- → 4
That gives a final mode of 0654, displayed as -rw-r-xr--, confirming A is correct. Choice B (0644, -rw-r--r--) is wrong because it ignores the g+x portion — it only accounts for o+r being added to the group, not execute. Choice C (0674, -rw-rwxr--) incorrectly applies g+x as if it's adding full write+execute, or conflates the group's starting bits — the group only had read (4), so adding execute yields 5, not 7. Choice D (0754, -rwxr-xr--) mistakenly adds execute to the owner bits, which neither command does. Your study tip: always resolve absolute chmod commands first to establish a baseline, then apply symbolic modifiers on top. Symbolic mode never resets — it only adds (+) or removes (-) from what's already there.

Question 6

A sudo policy authorizes Kai to run only /usr/bin/systemctl restart web.service as root. It does not contain broader rules, wildcards, or permission to start a root shell.

Which action should the policy permit?

  1. Run sudo /usr/bin/systemctl restart web.service using the authorized command and arguments. (correct answer)
  2. Run sudo /usr/bin/systemctl stop web.service because it uses the same executable and service.
  3. Run sudo /usr/bin/cat /etc/shadow because any successful sudo rule grants root access.
  4. Run sudo -i because authorization for one root command implies permission for a root shell.
Explanation: When you see a question about sudo policies, think about the principle of least privilege: a policy grants exactly what it specifies — nothing more, nothing less. The policy here is precise: Kai may run /usr/bin/systemctl restart web.service as root. That's one executable, one subcommand, one service name. Choice A is correct because it matches the authorized command character-for-character. Sudo performs an exact comparison against the policy; when the command, subcommand, and arguments align with what's written, access is granted. This is the intended, safe behavior. Choice B is a common trap — it assumes "same binary, same service" is close enough. It isn't. The policy authorizes restart, not stop. Sudo doesn't interpret intent or family resemblance; it matches strings. Allowing adjacent subcommands would silently expand privileges beyond what was approved. Choice C reflects a fundamental misconception: that any sudo rule grants general root access. In reality, a restricted sudo entry is specifically designed to avoid giving root access broadly. Kai cannot run /usr/bin/cat /etc/shadow because that command never appears in the policy. Choice D conflates "authorized to run one root-level command" with "authorized to become root." Running sudo -i opens an interactive root shell — a dramatically broader privilege. The policy explicitly grants no such thing, and well-written sudo configurations restrict shell access precisely to prevent this escalation path. Your study tip: on any privilege-related exam question, ask yourself "does the policy explicitly authorize this exact action?" Proximity, similarity, or logical inference never substitute for explicit permission in access control.

Question 7

A directory /srv/drop is owned by admin:editors and has mode 0770. Inside it, report.txt is owned by root:root and has mode 0444. Ben belongs to editors. The directory has no sticky bit, and no ACLs or special file attributes apply.

Which statement best describes what Ben can do?

  1. Ben can modify the file's contents but cannot remove its directory entry.
  2. Ben can remove the file but cannot directly modify its contents through the file. (correct answer)
  3. Ben can read the file but can neither modify nor remove it from the directory.
  4. Ben cannot access the file because its owner and group are both root.
Explanation: When Unix permissions questions involve a file inside a directory, you need to check two separate permission sets: the directory's permissions (which control the directory's contents as a namespace) and the file's permissions (which control the file's data). These are independent, and both matter. Ben belongs to editors, so he has group access to /srv/drop, which has mode 0770. That grants him full read, write, and execute on the directory itself. Write permission on a directory means Ben can add or remove directory entries — including unlinking report.txt from the directory — regardless of who owns the file. Execute permission lets him traverse into it and look up filenames. Now look at report.txt: owned by root:root, mode 0444. Ben is neither the owner nor in the file's group, so he falls into the "other" category — and "other" gets 4 (read-only). He can read the file's contents, but he cannot write to it directly. Crucially, there is no sticky bit on /srv/drop, which would otherwise prevent non-owners from deleting files they don't own. Without it, directory write permission is all that matters for deletion. So Ben can remove the file (via the directory) but cannot modify its contents. That's exactly what B says. Choice A has it backwards — Ben can remove the entry but cannot modify the contents. Choice C undersells his directory privileges; he absolutely can remove the file. Choice D is a common misconception: file ownership affects file-level permissions, but directory access is governed by the directory's permission bits, not the file's owner. Remember the rule: deletion is a directory operation, modification is a file operation — always check both separately.

Question 8

To make a website's content readable, an administrator runs sudo chmod -R 644 /var/www/site. Regular pages now have read permission, but the unprivileged web service can no longer retrieve them. All parent directories above site remain traversable.

What is the most likely cause and appropriate correction?

  1. The execute bit matters only for program files; mark every website file executable to restore access.
  2. The recursive command removed write from regular files; grant write to all users so pages can be served.
  3. The recursive option changed only symbolic links; rerun the command without -R to affect directories.
  4. The recursive command removed execute from directories; restore directory traversal while keeping regular files non-executable. (correct answer)
Explanation: When working with Linux file permissions, you need to think about two distinct permission contexts: files and directories. The execute bit (x) means something different for each — for files, it allows execution as a program; for directories, it controls traversal, meaning whether a process can enter or pass through that directory to access its contents. The command chmod -R 644 sets permissions recursively to rw-r--r-- — removing execute from everything it touches, including subdirectories inside /var/www/site. Even though the files themselves are readable (r--), the web service can't retrieve them because it can't traverse the directories containing them. The kernel checks execute permission on each directory in a path before granting access to the file inside. D correctly identifies this: the recursive command stripped directory execute bits, and the fix is restoring them (typically 755 for directories) while leaving regular files at 644. A is wrong because marking website files executable is both unnecessary and a security risk — files don't need the execute bit to be served over HTTP, only to run as programs. B is wrong because write permission is irrelevant to serving static content; adding world-write to files would be a serious vulnerability, not a fix. C is wrong because -R doesn't "only change symbolic links" — it recursively affects all files and directories in the tree; this answer is simply fabricated nonsense. Study tip: Remember the phrase "directories need execute to enter." When a recursive chmod breaks directory access, your first instinct should be to check whether directory traversal (x) was accidentally removed — a common real-world misconfiguration.

Question 9

The directory /projects has mode 0711. Its subdirectory /projects/blue, owned by Maria, has mode 0700. The file /projects/blue/status.txt has mode 0644. Noah is neither Maria nor a member of any relevant group, but he knows the complete filename. No ACLs apply.

Which single permission change by Maria would minimally allow Noah to read status.txt without allowing him to list the contents of /projects/blue?

  1. Run chmod o+r /projects/blue to let Noah read directory entries.
  2. Run chmod o+x /projects/blue to let Noah traverse the known path. (correct answer)
  3. Run chmod o+x /projects/blue/status.txt to make the file accessible.
  4. Run chmod o+r /projects to let Noah read the top-level directory.
Explanation: Whenever you see a Linux file permissions question, think in terms of the path traversal chain: to access any file, a user must have execute (x) permission on every directory in the path leading to it. Reading a directory (the r bit) lets you list its contents — that's a separate capability. Here's the chain Noah needs to reach /projects/blue/status.txt: he must traverse /projects, then /projects/blue, then read the file itself. The top-level /projects already has mode 0711, meaning others have execute permission — Noah can traverse it. The file status.txt has mode 0644, so others already have read permission. The missing link is /projects/blue, which is 0700 — others have no permissions at all. Adding o+x grants Noah the ability to traverse into the directory using a known path, without revealing directory contents (that would require r). This is exactly what B does, and it's the minimal, targeted fix. A is wrong because o+r on /projects/blue grants the ability to list directory entries — precisely what the question says to avoid. C is wrong because the file's execute bit has nothing to do with reading a regular file; o+x on a text file would only matter if it were a script being executed, and it still wouldn't fix the directory traversal block. D is wrong because /projects already allows others to traverse it (0711 includes o+x), so adding o+r there is unnecessary and irrelevant. A useful memory anchor: r on a directory = list, x on a directory = enter. Keep these two completely separate in your mind on exam day.

Question 10

The file plans.txt is owned by alice:developers and has mode 0040, displayed as ----r-----. Alice is also a member of the developers group. No ACLs or other special controls apply.

What happens when Alice attempts to read plans.txt?

  1. The read succeeds because Alice receives the union of the owner and group permissions.
  2. The read succeeds because group permissions take precedence whenever they are less restrictive.
  3. The read fails because the owner permission class applies without falling back to the group class. (correct answer)
  4. The read fails because a readable file must also grant execute permission to its owner.
Explanation: When a process tries to access a file on a Unix-like system, the kernel checks permission classes in strict order — owner first, then group, then others — and stops at the first matching class. It does not combine classes or shop around for the most permissive one. Here, plans.txt has mode 0040: the owner class has no permissions (---), the group class has read (r--), and others have nothing. Alice is the file's owner, so the kernel matches her to the owner class immediately and evaluates only those bits — which grant nothing. The read fails. The group class is never consulted, even though Alice is also in developers and that class would allow the read. A is wrong because Unix permissions are never unioned across classes. The kernel picks exactly one class per access attempt — whichever matches first — and applies only those bits. B contains a related misconception: the system has no concept of "less restrictive wins." The owner class always takes priority over the group class, regardless of which grants more access. D invents a rule that doesn't exist; execute permission on a file has nothing to do with whether read access is granted — those bits are independent. So C is correct: Alice's access is governed solely by the owner permission class, which denies her, and there is no fallback to the group class. Study tip: Memorize the matching order — owner → group → other — and remember it's first-match-only, not best-match. This "no fallback" rule is a classic exam trap, especially when the owner is also a group member.