23 Permissions, Files & Accounts Practice Questions & Answers

1. 1. A user named bob runs cat /srv/data/report.csv and gets "Permission denied". ls -l on the file shows -rwxrwxrwx 1 root root, and ls -ld /srv/data shows drwxr-x--- 2 root root. What explains the denial?

   • A.The file belongs to group root, so bob is checked against the group class instead.
   • B.bob lacks execute permission on /srv/data, so he cannot traverse it to open the file inside.✓ Answer
   • C.World-writable files are refused by the kernel unless the reader owns the file.
   • D.cat needs read permission on the parent directory, and bob's class does not hold it.

   Execute permission on a directory is search (traverse) permission: it is required to resolve any name through that directory. Because bob falls in the "other" class of /srv/data, which has ---, path resolution stops there and the file's own 777 mode is never consulted. Read permission on a directory only allows listing names; it is not enough to reach the entries.

   Source: path_resolution(7) manual page — directory search (execute) permissionReport a problem with this question

2. 2. ls -l /shared/notes.txt shows -r--r--r-- 1 alice alice, and ls -ld /shared shows drwxrwxrwx 2 root root. User carol, who is neither alice nor root, deletes the file successfully. What explains this?

   • A.Write and execute permission on the directory control who can remove an entry.✓ Answer
   • B.A read-only file can still be unlinked by anyone, because rm ignores the file's mode.
   • C.Mode 444 grants the other class delete rights along with read access to the data.
   • D.Only the directory's owner may remove entries, and carol holds that right from root.

   Removing a name is a modification of the directory that holds it, so the kernel checks write and execute permission on that directory, not the permissions of the file being removed. /shared is mode 777 with no restricted-deletion flag, so any user may unlink entries there regardless of who owns them.

   Source: unlink(2) manual page — write and execute permission on the containing directoryReport a problem with this question

3. 3. An administrator runs chmod 2750 on the directory /srv/team. Which permission string will ls -ld then display for it?

   • A.drwxr-s---✓ Answer
   • B.drwsr-x---
   • C.drwxr-S---
   • D.drwxr-x--T

   In a four-digit octal mode the leading digit carries the special bits: 4 is set-user-ID, 2 is set-group-ID and 1 is the restricted-deletion flag. So 2750 means set-group-ID plus rwx for the owner, r-x for the group and nothing for others; the set-group-ID bit appears in the group execute slot as a lowercase s because the group execute bit is also present.

   Source: chmod(1) manual page — octal modes and the set-group-ID bitReport a problem with this question

4. 4. ls -l /usr/bin/passwd shows -rwsr-xr-x 1 root root. Expressed as a four-digit octal mode, what is that permission set?

   • A.4755✓ Answer
   • B.2755
   • C.6755
   • D.1755

   The lowercase s in the owner execute position means the set-user-ID bit is set and the owner also has execute, which is octal 4 in the special digit. The three triplets rwx, r-x, r-x are 7, 5 and 5, giving 4755. A set-user-ID program runs with the effective user ID of the file's owner rather than the caller's.

   Source: chmod(1) and chmod(2) manual pages — set-user-ID bit in four-digit octal modesReport a problem with this question

5. 5. A user's shell has umask 027 in effect. She creates a regular file with an output redirect and a directory with mkdir, touching neither afterwards. What modes do the two end up with?

   • A.The file becomes 644 and the directory becomes 755.
   • B.The file becomes 750 and the directory becomes 750.
   • C.The file becomes 640 and the directory becomes 750.✓ Answer
   • D.The file becomes 639 and the directory becomes 750.

   The mask clears bits from a base mode of 666 for regular files and 777 for directories, so 666 with 027 removed gives 640 and 777 with 027 removed gives 750. It is bit clearing, not decimal subtraction, and regular files never receive execute permission at creation no matter what the mask allows.

   Source: umask(1p), POSIX shell and utilities specification — file mode creation maskReport a problem with this question

6. 6. A regular user owns report.csv and wants user dave to become its owner. She runs chown dave report.csv and gets "Operation not permitted". What rule is she running into?

   • A.The command must name a group as well, written as chown dave:dave report.csv.
   • B.chown refuses files whose group differs from the new owner's primary group.
   • C.A file can change hands once its mode is set to 666 for every permission class.
   • D.Assigning a new owner to a file is a privileged operation reserved for root.✓ Answer

   Linux does not let an unprivileged user give a file away, because that would allow quota and accounting evasion; only a privileged process may change a file's user ID. The owner may still change the group with chgrp or chown :group, but only to a group of which she is a member.

   Source: chown(2) manual page — changing file ownership requires privilegeReport a problem with this question

7. 7. Members of group devs must be able to edit one another's files in /srv/project, and every new file created there has to belong to group devs. The directory is already chgrp devs and mode 770. Which step produces that group inheritance?

   • A.Set the set-user-ID bit on the directory with chmod u+s /srv/project.
   • B.Set the restricted-deletion flag on the directory with chmod +t /srv/project.
   • C.Set the set-group-ID bit on the directory with chmod g+s /srv/project.✓ Answer
   • D.Make devs the primary group of each member with usermod -g devs on every account.

   The set-group-ID bit on a directory makes newly created entries take the directory's group instead of the creator's primary group, and new subdirectories inherit the bit as well. The set-user-ID bit has no such meaning on a directory, and the restricted-deletion flag governs who may delete entries rather than which group new files get.

   Source: chmod(1) manual page — set-group-ID on directoriesReport a problem with this question

8. 8. ls -ld /tmp shows drwxrwxrwt. A shared upload directory at /var/spool/upload is drwxrwxrwx and users keep deleting each other's files there. What does adding the final t do?

   • A.Removal or renaming of an entry becomes limited to the entry's owner, the directory's owner, or root.✓ Answer
   • B.Files inside are made read-only for every user except root, so nothing can change.
   • C.Writes to existing files become limited to their owners, while new entries are still free.
   • D.The directory's group is inherited by every new entry, and delete rights follow that group.

   The restricted-deletion flag, shown as t in the other execute position, is what makes a world-writable directory safe: everyone may still create files, but only the file's owner, the directory's owner or a privileged process may unlink or rename an existing entry. That is exactly why /tmp is mode 1777.

   Source: chmod(1) manual page — restricted deletion flag; Filesystem Hierarchy Standard, /tmpReport a problem with this question

9. 9. ls -l /usr/local/bin/collect shows -rwSr--r-- 1 root root. What does the capital S in the owner triplet tell the administrator?

   • A.The set-group-ID bit is set, so the program runs with the privileges of its own group.
   • B.The set-user-ID bit is set, but the owner's execute bit is absent, so the bit has no effect.✓ Answer
   • C.The owner holds execute permission together with set-user-ID, which a capital letter marks.
   • D.The file carries the immutable attribute, which ls renders inside the owner triplet.

   ls prints a lowercase s when a special bit and the corresponding execute bit are both present, and an uppercase S when the special bit is set but the execute bit is missing. A set-user-ID file with no execute permission for its owner cannot be run at all through that class, so the bit is inert and usually signals a mistake such as chmod 4644.

   Source: ls(1) manual page — mode string notation for set-user-ID without executeReport a problem with this question

10. 10. A directory is drwxrws--- 2 root devs. Member sam creates a file in it and ls -l shows -rw-r--r-- 1 sam devs. Teammates in devs can read the file but cannot edit it. What accounts for the missing group write bit?

    • A.The set-group-ID bit copies the group name but also forces mode 644 on new files.
    • B.Group members have to run newgrp devs first, since the file was created under another group.
    • C.The directory's group write bit applies to its own entry rather than to the files inside.
    • D.The creating user's umask cleared group write, which the set-group-ID bit does not restore.✓ Answer

    The set-group-ID bit on a directory controls only the group ownership of new entries; the permission bits of a new file still come from the creating process's requested mode reduced by its umask. With a mask of 022 the group write bit is cleared, so a collaborative directory normally needs a mask such as 002 as well as the set-group-ID bit.

    Source: chmod(1) manual page and umask(1p) — set-group-ID directories and the creation maskReport a problem with this question

11. 11. getfacl budget.ods prints these lines: user::rw-, user:jan:rw- #effective:r--, group::r--, mask::r--, other::---. jan reports she cannot save changes. What is blocking her?

    • A.The change needs a remount, because ACL entries take effect at mount time only.
    • B.Her named entry sits below the owning group entry, which grants read access here.
    • C.Named user entries are ignored for writes, so the other class decides the outcome.
    • D.The mask entry caps every named entry at read, so jan's write permission is clipped.✓ Answer

    The mask entry is an upper bound on the permissions of all named user entries, named group entries and the owning group entry, and getfacl marks the clipped result with #effective. Raising the mask, for example with setfacl -m m::rw budget.ods, restores jan's write access; note that chmod g+w on a file with ACLs edits the mask rather than the group entry.

    Source: acl(5) manual page — ACL mask entry and effective permissionsReport a problem with this question

12. 12. New files created in /srv/audit must automatically give group auditors read and write, whatever umask the creating user happens to have. Which approach sets that up?

    • A.Add an access entry for the group with setfacl -m g:auditors:rw /srv/audit.
    • B.Add group write on the directory with chmod g+rwx and chgrp auditors /srv/audit.
    • C.Add the set-group-ID bit with chmod g+s /srv/audit so the group reaches new files.
    • D.Add a default entry for the group with setfacl -m d:g:auditors:rw /srv/audit.✓ Answer

    A default ACL, set with the d: prefix on a directory, is inherited by every file and subdirectory created inside it and is applied instead of relying on the creator's umask. A plain access entry only governs the directory itself, and the set-group-ID bit passes on the group without granting write permission.

    Source: setfacl(1) manual page — default ACL entries on directoriesReport a problem with this question

13. 13. root cannot change or remove /etc/app/licence.conf: an editor and rm both report "Operation not permitted". The mode is -rw-r--r-- 1 root root, the filesystem is mounted read-write, and lsattr prints ----i---------e----- for the file. What is going on?

    • A.The append-only attribute is set, so writes have to be redirected with >> instead.
    • B.The file is owned by root with mode 644, so write access needs a chmod u+w beforehand.
    • C.The extent-format attribute shown as e holds the file read-only until the volume is remounted.
    • D.The immutable attribute is set, and chattr -i must clear it before any change is possible.✓ Answer

    The i flag in lsattr output is the immutable attribute: while it is set, the file cannot be modified, deleted, renamed or given new hard links, and even a privileged process is refused with "Operation not permitted". Only clearing it with chattr -i restores normal behaviour; the e flag merely records that the file uses extents.

    Source: chattr(1) manual page — immutable attributeReport a problem with this question

14. 14. An administrator runs ln /data/orig.log /data/copy.log, then stat on each name. Both report the same inode number and "Links: 2". She then removes /data/orig.log. What is the state of the data afterwards?

    • A.The data is gone, because unlinking the first name releases the inode behind it.
    • B.The data stays reachable through /data/copy.log, and the link count falls to one.✓ Answer
    • C.The data stays and the count remains two, since stat caches the value until unmount.
    • D.The data stays, but /data/copy.log now resolves to an empty file until it is relinked.

    A hard link is simply an additional directory entry pointing at the same inode, so there is no original and no copy: the two names are equal. Removing one name decrements the link count and the inode with its data is freed only when the count reaches zero and no process still holds the file open.

    Source: ln(1) and stat(1) manual pages — hard links, inodes and link countsReport a problem with this question

15. 15. /home sits on one filesystem and /srv on another. The command ln /home/ana/data.csv /srv/share/data.csv fails with "Invalid cross-device link". What should the administrator do, and why?

    • A.Create a symbolic link with ln -s, because a hard link cannot span two filesystems.✓ Answer
    • B.Force the link with ln -f, because the failure comes from the target name existing.
    • C.Copy the file with cp -l, because that option makes hard links across filesystems.
    • D.Remount /srv with the hardlinks option, because the mount refused a second entry.

    A hard link is a directory entry referring to an inode number, and inode numbers are only meaningful inside one filesystem, so the kernel rejects the attempt with EXDEV. A symbolic link stores a pathname in its own inode instead, which is why it can cross filesystems and can also point at a directory.

    Source: ln(1) manual page and link(2) EXDEV error — hard links within one filesystemReport a problem with this question

16. 16. ls -l /etc/app/current shows lrwxrwxrwx 1 root root 20 current -> /opt/app/spring/bin. After a colleague renames /opt/app/spring, users opening /etc/app/current get "No such file or directory". He argues that the link's own rwxrwxrwx mode should still allow access. What is actually true?

    • A.A symbolic link holds the target's inode, so the rename should have been followed.
    • B.A symbolic link holds a path string, so renaming its target leaves it dangling and broken.✓ Answer
    • C.The mode lrwxrwxrwx grants access, so a read-only mount must be causing the error.
    • D.A symbolic link keeps its own copy of the data, which the rename left empty.

    A symbolic link stores a pathname, which is resolved afresh on every access, so renaming or deleting the target turns the link into a dangling link. The permissions displayed on a symbolic link are fixed at rwxrwxrwx and are never used for access decisions: the target's ownership and mode govern, and the fix here is to repoint the link with ln -sfn.

    Source: symlink(7) manual page — symbolic link resolution and dangling linksReport a problem with this question

17. 17. In one directory, ls -l shows four entries whose mode strings begin prw-r--r--, srwxrwxrwx, brw-rw---- and crw-rw-rw-. What kinds of files are these four, in that order?

    • A.A pipe file, a symbolic link, a backup device and a copy-on-write file, in that order.
    • B.A print queue, a stream, a boot partition and a console log, in that order.
    • C.A named pipe, a socket, a block device and a character device, in that order.✓ Answer
    • D.A process file, a shared file, a buffered file and a cached file, in that order.

    The first character of the mode string is the file type: - regular, d directory, l symbolic link, p FIFO or named pipe, s socket, b block device and c character device. Block devices are addressed in fixed-size blocks through the buffer cache, while character devices are unbuffered byte streams, and for both ls prints major and minor numbers where the size normally appears.

    Source: ls(1) manual page — file type characters in the mode string; inode(7)Report a problem with this question

18. 18. User ravi is a member of the supplementary groups docker and wheel. An administrator runs usermod -G developers ravi, and ravi immediately loses the access those two groups gave him. What happened, and what was intended?

    • A.The -G form changed the primary group, and the supplementary list needs -aG.
    • B.The -G form takes effect at next login, so the lost access returns after a reboot.
    • C.The -G form replaced the whole supplementary list, where -aG appends instead.✓ Answer
    • D.The -G form deleted ravi's /etc/group entries, which groupmod -a would restore.

    usermod -G sets the supplementary group list to exactly the groups named, silently removing the account from any group that is not listed; -a modifies -G so the named groups are appended to the existing list. Primary group membership is a separate setting changed with -g, and a new group membership only affects sessions started afterwards, or a shell that runs newgrp.

    Source: usermod(8) manual page — the -a option used with -GReport a problem with this question

19. 19. An administrator runs passwd -l dana and confirms that dana's hash in /etc/shadow now begins with an exclamation mark. Dana still logs in over SSH with her public key. Why does that still work?

    • A.Locking covers console logins, while SSH consults its own credential database.
    • B.Locking takes effect at the next password change, so present access simply continues.
    • C.Locking prefixes the stored hash, which blocks password logins but not key-based ones.✓ Answer
    • D.Locking clears the account's shell, and key-based logins skip the shell entirely.

    Locking a password writes an exclamation mark in front of the stored hash so that no supplied password can ever match it, but it changes nothing else about the account. Public-key authentication never consults that field, so disabling access completely requires expiring the account itself or removing the authorized key.

    Source: passwd(1) and shadow(5) manual pages — password lockingReport a problem with this question

20. 20. A contractor's access must stop at once, by every interactive method, while her home directory and files stay on the server for an audit. Which single action does that?

    • A.Lock the password with passwd -l, which refuses every login method for that user.
    • B.Expire the account itself with chage -E 0, which refuses every login for that user.✓ Answer
    • C.Remove the account with userdel -r, which stops logins and keeps the files in place.
    • D.Set the login shell to /bin/false, which refuses every authentication attempt made.

    Setting the account expiration field in the past, which chage -E 0 does, disables the account itself, so no authentication method succeeds while the home directory and files remain untouched. Locking the password leaves key-based logins working, a non-login shell only prevents an interactive shell, and userdel -r deletes the home directory and mail spool.

    Source: chage(1) and shadow(5) manual pages — account expiration fieldReport a problem with this question

21. 21. A line in /etc/passwd reads: backupsvc:x:0:0:backup agent:/var/lib/backupsvc:/bin/bash. What is the most significant fact about this entry?

    • A.The second field is x, so this account can authenticate with no password at all.
    • B.The third field is 0, so this account holds full root privilege on the system.✓ Answer
    • C.The home lies under /var/lib, so the kernel treats the account as unprivileged.
    • D.The name ends in svc, so the system confines the account to service duties.

    The seven colon-separated fields are name, password placeholder, UID, GID, comment, home directory and login shell, and the kernel makes all privilege decisions from the numeric UID alone. Any account with UID 0 is root-equivalent whatever it is called, while x in the second field merely says the password hash lives in /etc/shadow.

    Source: passwd(5) manual page — field layout and the meaning of UID 0Report a problem with this question

22. 22. id sam prints uid=1007(sam) gid=1007(sam) groups=1007(sam),1200(devs),1300(qa). The devs line in /etc/group lists sam among its members, but the line for sam's own group does not list him at all. Why not?

    • A.Primary group membership is recorded in the /etc/passwd entry, not in the member list.✓ Answer
    • B.The member list holds accounts added with gpasswd, and useradd skips that step.
    • C.Primary groups live in /etc/gshadow, which is where sam's name was written.
    • D.A group leaves out its own members whenever the group name matches the user name.

    A user's primary group is the GID in the fourth field of his /etc/passwd line, so it is never duplicated in the member list of /etc/group; the four fields of a group line are name, password, GID and the list of supplementary members. That is why id, which merges both sources, shows a group that grep on /etc/group alone would miss.

    Source: passwd(5) and group(5) manual pages — primary and supplementary group membershipReport a problem with this question

23. 23. An administrator adds a site-wide alias file to /etc/skel and expects existing users to pick it up at their next login. They never see it, although accounts created afterwards do have it. Why?

    • A.The contents of /etc/skel apply once /etc/profile is regenerated with useradd -D.
    • B.The contents of /etc/skel are read at every login, so those users must log out first.
    • C.The contents of /etc/skel are copied into a home directory at the moment it is created.✓ Answer
    • D.The contents of /etc/skel reach existing homes when their mode is raised to 755.

    /etc/skel is a one-time template: useradd copies it into the new home directory only when it creates that home, so later edits never reach homes that already exist. Settings that must apply to everyone belong in a system-wide login file such as /etc/profile or a drop-in under /etc/profile.d instead.

    Source: useradd(8) manual page — /etc/skel and home directory creationReport a problem with this question

Practice questions written to the published CompTIA Linux+ exam objectives and to standard Linux administration practice. CompTIA and Linux+ are marks of CompTIA, and Linux is a registered trademark of Linus Torvalds; this site is not affiliated with or endorsed by CompTIA. The real exam mixes multiple-choice items with performance-based questions that ask you to carry out a task in a simulated environment — those cannot be reproduced in a four-option format, so this bank covers the knowledge half and you should practise on a real system alongside it. CompTIA revises and version-numbers the objectives periodically: confirm the current objectives, exam code and requirements with CompTIA before testing. About the CompTIA Linux+ certification →