Security And File Permissions practice questions

chmod 655 deploy.sh

Why it fails: 655 grants read/write to owner, but execute to group and others, which is insecure.

chown u+x deploy.sh

Why it fails: chown changes ownership, not permissions.

chmod +w deploy.sh

Why it fails: This adds write permission, not execute permission.

/etc/hosts

Why it fails: Used for hostname resolution.

/etc/fstab

Why it fails: Used for file system mounting.

/etc/shadow

Why it fails: While important for security, passwd and group are the primary management files.

passwd -e

Why it fails: passwd -e expires the password immediately, but chage is more comprehensive for management.

usermod -e

Why it fails: usermod -e sets the account expiration date, not the password expiration.

userdel -p

Why it fails: Command does not exist.

Cannot be locked.

Why it fails: The root account can be locked, for example by prefixing the password hash in /etc/shadow with an exclamation mark, so this statement is false. It tempts because root is conventionally never locked in practice and many distributions ship it with no password set. The genuine characteristics are a UID of 0 and unrestricted privileges.

Must have a shell set to /bin/bash.

Why it fails: Root's shell is defined in /etc/passwd and can be any valid shell, including /bin/sh or /sbin/nologin, so /bin/bash is not required. It tempts because bash is the default interactive shell on most distributions and root commonly uses it. The actual characteristics are UID 0 and unrestricted access to all files and commands.

Is always member of the 'users' group.

Why it fails: root's group memberships are defined by /etc/group entries, not fixed; root's primary group is root (GID 0) and it need not belong to users. It tempts because root can access anything users can, but that is a permission-override effect, not group membership, so the statement is false.

Run chmod g+rwx /srv/payroll and tell the audit user to access the path directly.

Why it fails: The group bits on this directory already include rwx, so this chmod changes nothing effective. The audit user is not in the finance group, and group permissions only apply to accounts listed as members of the owning group. Adding permissions the group already possesses does not extend access to a user outside that group.

Run setfacl -R -m u:audit:rx /srv/payroll to propagate access to every child object.

Why it fails: The recursive ACL modification does grant the audit user access, but it rewrites the ACL on every file already inside the directory, which the requirement explicitly forbids. Even though setfacl exists on many Linux systems, modifying existing objects' metadata contradicts the stated constraint. A default ACL would be needed for future files, not a recursive change to current ones.

Run chmod o+rx on the directory so the audit user is covered by the others category.

Why it fails: Granting others read and execute on the directory would open it to every account on the system, not just the audit user, which violates least privilege on payroll data. It also does not address the individual files' permission bits, and it weakens the directory's protection far beyond what the scenario requires. The audit user is a member of a group, not an anonymous other.

getfacl -R / | grep -i suid

Why it fails: getfacl displays POSIX access control lists, not the traditional SUID or SGID mode bits. Grepping for 'suid' will not find files with the setuid bit because ACL output does not include that field. This command is useful for extended ACLs but unsuitable for finding SUID or SGID executables.

ls -lR / | grep '^...s'

Why it fails: The ls -lR listing shows permissions, but the grep pattern '^...s' is unreliable: it only matches an 's' in the fourth character position, which corresponds to the user execute slot for SUID, and misses SGID entirely. It also depends on parsing human-readable output, which is fragile across locales and file types.

stat --format='%A %n' / | grep 's'

Why it fails: stat can show the permission string, but running it on / alone does not recurse into subdirectories, so it will not discover files anywhere else. Even with recursion, grepping for 's' would also match unrelated characters. It does not reliably enumerate SUID or SGID files across the filesystem.

chmod u+rw,g+r,o-rwx report.txt

Why it fails: This command adds read and write for the user, adds read for the group, and removes all permissions for others. If the file already had execute bits or extra permissions for user or group, those would remain, potentially resulting in a mode like 760 or 740 rather than 640. The requirement is to ensure exactly read and write for alice and read for finance, so additive changes are unreliable.

chmod 660 report.txt

Why it fails: Octal 660 grants read and write to both the user and the group. That would allow the finance group to modify the file, which violates the scenario's requirement that the group should only be able to read it. The correct mode must restrict the group to read-only, so 660 is too permissive for this case.

chmod a=rw report.txt

Why it fails: The a=rw syntax sets read and write permissions for all three classes: user, group, and others. This would give everyone on the system read and write access to report.txt, directly contradicting the requirement that others have no access. It also grants write to the group, which is not desired. This command is far too permissive.

Read permission on a file is sufficient to modify its contents, provided the user also owns the file.

Why it fails: Read and write are distinct bits. Owning a file does not let a process write to it unless the owner write bit is set; ownership only determines which category of bits is evaluated. A file with mode 400 is readable but not writable even by its owner, so read permission alone never implies the ability to change contents.

The root user is subject to the same first-match-wins rule as ordinary users and can be denied by a mode of 000.

Why it fails: Root bypasses the normal permission checks for most file operations, so a mode of 000 does not stop root from reading or writing a regular file. The kernel grants privileged processes access regardless of the mode bits, though special cases such as execute permission on a binary still matter. Ordinary users, by contrast, are fully bound by the ordered evaluation.

If a process's effective UID matches the file owner, the group and others bits are also combined to grant the widest possible access.

Why it fails: The categories are not additive. Once the owner category matches, only the owner permission bits are evaluated, even if the group or others bits would be more permissive. This is why a file with mode 600 denies access to the owner's own group members: the owner match short-circuits the check, and no union of bits occurs.

chmod 700 /home/dev/deploy.sh

Why it fails: Mode 700 grants the owner read, write, and execute, and denies all access to group and others. While it does block other users, it also adds execute permission for the owner, which may be unnecessary and could allow accidental execution. The requirement is to deny access to others, but 600 is more precise for a non-executable script file.

chmod 640 /home/dev/deploy.sh

Why it fails: Mode 640 allows the owning group to read the file. If the developer's group includes other users, they would still be able to read the script, violating the requirement to prevent other users from reading it. It also leaves group read access, which is not desired.

chmod 444 /home/dev/deploy.sh

Why it fails: Mode 444 gives read permission to owner, group, and others, which is the opposite of what is needed. It would allow everyone on the system to read the script. This fails to restrict access and does not meet the security requirement.

chmod 755 /usr/local/bin/backup.sh

Why it fails: While chmod 755 does remove the setuid bit, it also removes any other special bits and sets the mode to rwxr-xr-x. However, the question asks for the command that specifically prevents root privilege execution while allowing all users to execute it. Using chmod 755 is a valid alternative, but it changes the mode wholesale rather than targeting the setuid bit, and could inadvertently affect other bits if present. The most precise answer is the one that removes only the setuid bit.

chmod g-s /usr/local/bin/backup.sh

Why it fails: The g-s option removes the setgid bit, which is not currently set on this file. The permissions -rwsr-xr-x show setuid in the user position, not setgid. Removing setgid would have no effect on the root privilege escalation because setuid is the active special bit. The script would still run with root's effective user ID.

chmod o-x /usr/local/bin/backup.sh

Why it fails: This command removes execute permission for others, which would prevent most users from running the script at all. The goal is to keep the script executable by all users while removing the root privilege escalation. Removing the execute bit for others does not address the setuid bit and actually breaks the requirement that all users can execute it.

chgrp projectteam /srv/project

Why it fails: This changes the group owner of the directory itself but does not modify how new files inside it are assigned groups. Without the SGID bit, newly created files will still take the creating user's primary group, so the policy would not be satisfied.

setfacl -m d:g:projectteam:rwx /srv/project

Why it fails: This sets a default ACL granting permissions to the projectteam group for new files, but it does not change the group ownership of those files. The policy specifically requires group ownership to be projectteam, which default ACLs alone do not enforce.

chmod u+s /srv/project

Why it fails: The u+s mode sets the SUID bit, which on a directory is ignored by Linux for access purposes and does not affect group ownership inheritance. SUID is relevant for executables, not for controlling the group of newly created files, so it fails to meet the requirement.

The directory's permissions are set to 777, which confuses the system.

Why it fails: Permissions of 777 grant read, write, and execute to everyone, so dave would definitely be able to enter. This mode does not cause any confusion; it is overly permissive. Therefore, it cannot explain why dave cannot cd into the directory.

The directory has the SGID bit set, which overrides execute permissions.

Why it fails: The SGID bit on a directory controls group ownership inheritance of new files and does not override or replace execute permissions. It does not prevent a user from entering the directory if execute permission is otherwise present. Thus, it cannot be the reason for dave's issue.

The directory lacks the sticky bit, preventing dave from entering.

Why it fails: The sticky bit on a directory restricts deletion or renaming of files to their owners, the directory owner, or root. It does not affect the ability to enter the directory. Therefore, its absence cannot be the cause of dave's inability to cd into /data/reports.

usermod -aG developers

Why it fails: usermod -aG adds a supplementary group to a user account, which affects that user's group membership but not the group assigned to files created in a directory. It is tempting because it involves the developers group, and would be correct when granting a user access to a group's resources.

chgrp developers /data

Why it fails: chgrp changes the group of the directory itself, not of files created inside it later; new files still inherit the creator's primary group. It is tempting because it targets group ownership directly, and would be correct for reassigning an existing file or directory rather than controlling inheritance.

chmod 1777 /data

Why it fails: The 1777 mode sets the sticky bit plus world-writable permissions, which restricts deletion but leaves group ownership as the creator's primary group. It is tempting because the sticky bit is associated with shared directories, and would be correct for a shared drop-box where users must not delete each other's files.

groupmod -n staff bob

Why it fails: groupmod -n renames a group, so this would rename group bob to staff rather than altering any user's primary group assignment. It is tempting because groupmod does modify group attributes, and would be correct when a group's name itself must change while its GID and members stay unchanged.

chgrp staff bob

Why it fails: chgrp alters a file or directory's group ownership, not a user's primary group membership; the username 'bob' is not a valid target for it. It is tempting because chgrp is the standard tool for changing group ownership, which would be correct when reassigning a file's group rather than a user's primary group.

usermod -G staff bob

Why it fails: `usermod -G` sets the supplementary group list, replacing bob's existing supplementary memberships rather than changing the primary group recorded in `/etc/passwd`. It is tempting because `-G` is the correct flag for adding a user to additional groups, which is what you would want when granting access to a shared resource without altering the account's primary group.

/etc/shadow

Why it fails: /etc/shadow stores password hashes and ageing data, not the UID; it is keyed by username but holds no numeric identifier. It is tempting because it is a core user-related file, yet it would be the correct choice when auditing password policy or checking whether an account is locked.

/etc/profile

Why it fails: /etc/profile holds shell environment and startup configuration, not user account records, so it contains no UID mapping. It is tempting because it is a familiar system-wide configuration file, but it would be the correct place to check when troubleshooting login environment variables or PATH settings.

/etc/group

Why it fails: /etc/group maps group names to GIDs and member lists, so it holds no user UID. It is tempting because it is a user administration file, but it would be the correct place to check when verifying a user's supplementary group memberships or a group's numeric identifier.

userdel jdoe

Why it fails: userdel removes the account and, without the -r flag, leaves files orphaned with no owner, so it neither locks the account nor cleanly preserves access. It is tempting because it immediately revokes login, which suits permanently decommissioning a departed user rather than a temporary compromise lockout.

killall -u jdoe

Why it fails: killall -u terminates the user's running processes but leaves the account able to authenticate and log in again, so it does not lock anything. It is tempting because it instantly severs active sessions, which suits stopping runaway processes rather than preventing future credential-based access.

chsh -s /bin/false jdoe

Why it fails: chsh changes the login shell to /bin/false, blocking interactive logins, but the account remains enabled and usable through other services such as FTP or scheduled jobs. It is tempting because it is non-destructive, which suits restricting shell access for service accounts rather than fully locking a compromised one.

Write (w)

Why it fails: Write permission allows creating, deleting and renaming entries; traversal requires execute (x). It tempts because write is commonly associated with full directory access, and it would be correct when users must add or remove files inside a directory they can already enter.

Sticky bit

Why it fails: The sticky bit restricts deletion within shared directories, granting no traversal right. It tempts because it is a directory permission bit, and it would be correct for shared writable directories such as /tmp where users must not delete each other's files.

Read (r)

Why it fails: Read permits listing directory entries but not traversal into it; execute (x) is the bit that lets a user enter and reach files inside. It is tempting because reading filenames feels like access, and read alone suffices when only listing contents is required.

chown root /tmp/shared

Why it fails: chown changes file ownership, not directory deletion semantics; restricting deletion of others' files requires the sticky bit, set via chmod +t. It tempts because ownership control sounds like access control. chown root would be correct when transferring a file or directory to the root account, which is unrelated to shared-directory deletion rules.

chmod 777 /tmp/shared

Why it fails: Mode 777 grants every user read, write and execute, letting anyone delete any file in the directory; the sticky bit (chmod +t, giving 1777) is what restricts deletion to each file's owner. It tempts because 777 is the familiar permissive setting for shared directories. 777 would be correct when unrestricted access is genuinely intended.

umask 077

Why it fails: The sticky bit (chmod +t) on the directory restricts deletion to each file's owner; umask 077 only strips group and other permissions on newly created files, so it cannot prevent one user deleting another's file in a shared, writable directory. Umask is the right tool for enforcing default private permissions on new files.

chown root:root file.conf

Why it fails: chown root:root only changes file ownership; root already bypasses discretionary permission checks, so ownership does not prevent root modifying or deleting the file. It is tempting because ownership underpins access control, making it correct when transferring a file to another user or service account that must own it.

chmod 400 file.conf

Why it fails: chmod 400 sets read-only permissions, but root bypasses discretionary permission checks, so root can still write or delete the file. It is tempting because it blocks standard users, making it correct when the requirement is to stop non-privileged accounts modifying a file while root retains normal access.

umask 000

Why it fails: umask 000 controls the default permission bits applied to newly created files; it does not alter existing files or restrict root, who bypasses permission checks entirely. It is tempting because it governs file permissions, making it correct when setting permissive defaults for a service account creating files in a shared directory.

id

Why it fails: The id command shows a user's UID, GID and supplementary group memberships, but the question asks for a tool that lists the groups themselves; groups is the dedicated command for that. id is tempting because it does reveal group membership, yet it requires already knowing the username.

listgroups

Why it fails: listgroups is not a standard Linux command; no such binary exists on typical distributions, so it returns command-not-found. It is tempting because the name describes the required function, but the actual tool is groups, which prints the group names for a specified user.

whoami

Why it fails: whoami prints the effective username and associated identifiers of the current process only; it accepts no username argument and never enumerates group membership. It is tempting because it reports identity information, but the groups command is what lists the groups a specified user belongs to.