CCNA Security And File Permissions Questions

The 'chattr +i' command sets the immutable attribute on a file, which prevents any modification, deletion, renaming, or even linking — even by the root user — until the attribute is removed with 'chattr -i'. This is the only option that satisfies the requirement of protecting the file from root itself.

The octal permissions 640 map exactly to owner read/write, group read, and others none. This is a direct application of the numeric notation, where each digit represents the sum of read (4), write (2), and execute (1) for the respective category. No other listed mode matches the specified access levels.

Mode 1777 on a directory combines world read/write/execute with the sticky bit. Write plus execute lets every user create entries, while the sticky bit limits deletion and renaming to the entry's owner, the directory's owner, or root. This is the classic shared drop-box pattern used by /tmp, balancing open creation with protection of existing files.

chmod 660 notes.txt sets the permissions to rw-rw----, meaning the owner and group both have read and write access, while others have no permissions at all. This matches the requirement that the group owner can read and write and nobody else can access the file. The leading 6 (rw-) applies to owner, the second 6 (rw-) to group, and the 0 (---) to others.

A leading 4 in a numeric mode sets the SUID bit on an executable. When run, the process takes on the effective user ID of the file's owner rather than the caller's. With root as owner, the script runs with root privileges, which explains why a standard user could perform restricted actions.

The /etc/passwd file stores one line per user account, with colon-separated fields where the third field is the numerical UID. Checking this file (or running getent passwd jdoe) reveals the UID assigned to 'jdoe'. It is world-readable, unlike /etc/shadow, so it is the standard place to look up account identifiers.

The groups command, run without arguments, reports the group set for the current effective user, including the primary group and supplementary groups. That makes it the correct single command for confirming the invoking user's memberships during an audit, without needing to inspect /etc/group manually.

The useradd utility provisions a new account entry in /etc/passwd and /etc/shadow, and the -m option additionally creates the home directory, copying default files from /etc/skel. It is the standard single-step method for adding a local user with an immediately usable environment, which is precisely what the scenario requires.

The setgid bit on a directory is the standard Linux mechanism for group inheritance: files and subdirectories created inside take the directory's group, and the bit is copied to new subdirectories. Setting it on a directory already group-owned by projects satisfies the requirement without editing /etc/passwd or /etc/group for individual users.

The /etc/shadow file stores encrypted password hashes along with password aging information for local user accounts. It is readable only by root, unlike /etc/passwd, which is world-readable and historically held the hashes.

Symbolic chmod lets you manipulate one permission category at a time. Because group ownership is already correct and only the group read bit is missing, selecting the group category and adding read yields exactly the intended access. The other forms either target the wrong category or widen access to all users, which the scenario explicitly does not want.

POSIX ACLs express per-user and per-group permissions on individual files, which is precisely what the scenario needs: read access for one named contractor on one log file. The traditional mode bits cannot represent a single extra user without widening the group or others categories, so setfacl is the least-privilege tool.

The groupdel command is the standard Linux utility used to remove a group from the system. It deletes the group entry from /etc/group and /etc/gshadow, and is the correct tool for this task.

The 's' in the owner's execute position (the fourth character of the permission string) indicates the setuid bit is set. When a setuid binary is executed, the process runs with the effective UID of the file's owner rather than the invoking user, which is how tools like /usr/bin/passwd let ordinary users modify /etc/shadow. The lowercase 's' means the underlying execute bit is also set; an uppercase 'S' would mean setuid is set but execute is not.

To add an existing user to an additional group, use usermod with the -aG options. The -a flag ensures the user is appended rather than replacing all current supplementary groups, and -G specifies the target group. This grants the needed access without disrupting other memberships.

The sticky bit (chmod +t) on a shared directory ensures that only the file's owner (or root) can delete or rename files within it, even if the directory is world-writable. This is exactly the behaviour needed for /tmp-style shared drop boxes where multiple users write files but must not remove each other's data. The kernel enforces this by checking the file owner against the deleting user before permitting unlink or rename.

The sticky bit on a directory limits deletion to the file's owner, the directory's owner, and root. Because contractors own their uploaded files and the administrator owns the directory, either could have unlinked the missing entry through normal means. The bit was never a guarantee against removal by those parties, so the disappearance is consistent with the directory's configured behavior.

The SGID bit on a directory changes group inheritance: files and subdirectories created within it receive the directory's group rather than the creator's primary group. Because /srv/reports is owned by root:finance, alice's new file is recorded as alice:finance. This is the standard mechanism for keeping shared project directories consistently group-owned so that all members of finance retain access.

To change only the group ownership of a file, the correct tool is chgrp. Because bob is a member of the auditors group, he has the necessary privilege to assign that group to his own file. The chgrp command leaves all permission bits untouched, satisfying the requirement to change group ownership without altering permissions.

For regular files, the requested creation mode is 666 because the kernel withholds execute bits from the base; the umask is then used to clear the corresponding bits. With umask 0022, group and other write are cleared, yielding 644, which ls shows as rw-r--r--. Directories differ because their base is 777, which is why the same umask produces rwxr-xr-x on a new directory.

useradd -m -d /home/guest guest creates the account 'guest', sets its home directory to /home/guest via -d, and -m ensures the directory is actually created and populated with skeleton files from /etc/skel. Without -m, useradd would record the home path but not create it.

Linux evaluates file permissions by checking the most specific category that applies to the user: owner first, then group, then others. Dave is not the owner and not in the hr group, so he falls into the others category, which has no permissions. Consequently, the kernel denies his read request, and he receives a permission denied error.

The setuid bit, set on an executable, makes the kernel run the resulting process with the effective UID of the file's owner. That is the only permission bit among the choices that changes the user identity of a running program. It is displayed as an s in the owner execute position of ls output.

chown (C) is correct because it directly changes the owner and/or group of files and directories, e.g. chown user:group file. chmod (E) is correct because it modifies file permission bits (read/write/execute for user, group, and others) using symbolic or octal modes. groupdel (A) only removes a group from the system and does not alter file ownership or permissions. useradd (B) creates new user accounts and does not touch existing files' ownership or permissions. usermod (D) modifies user account attributes such as group membership or shell, but it does not change file ownership or permissions.

The chown command accepts the syntax 'chown user:group file' to change both owner and group in a single invocation. Using the colon as a separator between user and group is the canonical POSIX form, and chown also accepts a dot (chown user.group file) on most Linux systems. Option C is the only choice that correctly combines both changes into one valid command.

Linux evaluates exactly one permission class per access: owner if the caller's UID matches, otherwise group if any of the caller's groups matches the file's group, otherwise others. A marketing user matches neither owner nor group, so only the trailing '---' applies, producing the denial. Understanding this single-class evaluation is essential when diagnosing access complaints.

Executing a file with ./ requires that the file carry execute permission for the invoking user, and chmod u+x grants exactly that to the owner. The other choices either set a mode without any execute bit, change ownership without adding execute, or attempt to elevate privileges around the missing bit. Only adding execute permission addresses the reported error directly.

The usermod command modifies existing user account attributes, and the -g flag specifically sets the user's primary group (the GID stored in /etc/passwd). Running 'usermod -g staff bob' changes bob's primary group to staff while leaving his supplementary group memberships intact. This is the standard, correct way to reassign a primary group on a Linux system.

On modern Linux systems, /etc/shadow is the file that stores encrypted password hashes along with password aging information such as the last change date, minimum and maximum password age, and expiration warnings. It is readable only by root, which protects the hashes from unauthorized access. The /etc/passwd file historically held password hashes but now contains only user account information, with the password field replaced by an 'x' that points to /etc/shadow.

Permission evaluation walks the owner, group, and others classes in order and stops at the first match. Because the contractor is a supplementary member of adm and the file grants read to group adm, the group class applies and access is allowed. Primary group switching or owner identity considerations do not change the outcome in this setup.

To view permissions of all files, including hidden ones, in a long listing format, the ls command needs both the -l and -a options. The -l option provides detailed information such as permissions, ownership, and size, while -a ensures that hidden files (those starting with a dot) are included. Combining them as ls -la achieves the desired output.

The chown command changes file ownership, and when only a user name is supplied, the group is preserved. Using the colon form would change both owner and group, violating the requirement. The chmod and chgrp commands address permissions and group ownership respectively, so neither can fulfill the stated ownership change.

`chmod g+s /data` sets the setgid (SGID) bit on the directory. When SGID is set on a directory, any file or subdirectory created inside inherits the directory's group ownership instead of the creating user's primary group. This is exactly the behavior needed for a shared 'developers' group directory.

The setgid bit on a directory makes new entries inherit the directory's group instead of the creator's primary group. Because the directory was set to 2775 with group devteam, any file created inside will belong to devteam while retaining the creator as user owner. The umask only strips permission bits and does not change group ownership.

The /etc/profile file is a system-wide initialization script executed by login shells for all users. Placing a umask 027 command there sets the default umask globally, affecting every user who starts a login shell. This is the standard location for system-wide environment and shell settings on Linux distributions that use the Bourne-compatible shell family.

The `groupadd` command is the standard Linux utility for creating a new group, and `groupadd audit` will create a group named 'audit' in the system's group database (/etc/group). This is part of the shadow-utils package and is the canonical way to add groups on Linux distributions.

The execute (x) bit on a directory grants the right to traverse it — that is, to access files and subdirectories by name within it. Without x, even if you have read permission, you cannot cd into the directory or open files whose paths pass through it.

Local account records live in /etc/passwd, and local group definitions with supplementary members live in /etc/group. Reading them together reveals which accounts exist, what login shells they have, and which groups each belongs to. The shadow file covers passwords, skel provides templates, and nsswitch merely directs lookup order, so those three do not supply the required listings.

On Linux, reading a file requires execute (x) permission on every directory in the path leading to the file. Even though the file's group permissions include read (the '4' in 640), the user cannot traverse into the directory containing the file without execute permission on that parent directory. This is the classic 'permission denied' scenario where file permissions look correct but directory traversal is blocked.

chmod 000 removes all permission bits (read, write, execute) for owner, group, and others, so no regular user can read, write, or execute the file. Root bypasses discretionary permission checks on most filesystems, so root can still access it. This is why the correct answer is that no user can access it except root.

Group ownership is stored as a numeric GID in the file's inode and is changed with chgrp, or equivalently with chown using a colon separator. Using chgrp accounting changes only that metadata field, so the subsequent permission bits for the group category will apply to accounting members. Tools that edit user accounts or that only touch mode bits cannot perform this change.

The groups command prints the group memberships for a specified user (or the current user if none is given), making it the direct answer. Running 'groups alice' lists every group alice belongs to, including her primary group and any supplementary groups. It reads from /etc/group and /etc/passwd (or NSS sources like LDAP/SSSD) to resolve memberships.

The userdel -r command removes the user account from /etc/passwd and /etc/shadow and also deletes the user's home directory and mail spool in one step. This is the standard, atomic way to fully decommission an account on Linux. Using -r ensures no orphaned home directory remains, which is important for security and disk hygiene.

The leading 1 in a numeric mode sets the sticky bit on a directory. When applied to a world-writable directory, it restricts deletion and renaming of files to the file owner, the directory owner, or root. This is exactly why users can create files but cannot delete files owned by others.

The permission 744 means the owner has read (4), write (2), and execute (1) = 7, while group and others each have read (4) only. This matches the requirement of read, write, and execute for the owner and read-only for group and others. The other options do not match this exact combination.

`usermod -L jdoe` locks the account by prepending an exclamation mark (!) to the password hash in /etc/shadow, immediately preventing password-based logins while leaving the user's home directory, files, UID, and group memberships fully intact. This is the standard, reversible administrative action for a compromised account because it disables authentication without destroying data or ownership.

The setgid bit on a directory is the standard mechanism for group inheritance. Once set, the kernel assigns the directory's group to every new file and subdirectory created within it, regardless of the creator's primary group. The sticky bit addresses deletion rights, and plain permission or ownership changes do not affect inheritance, so only the setgid approach meets the requirement.

With permissions 600 (rw-------), only the file owner (root) has read and write access; group and other have no permissions at all. A regular user falls into the 'other' category, so the kernel denies the read attempt with EACCES (Permission denied). This is standard POSIX discretionary access control behavior — the owner bits apply only to UID 0 in this case, and no ACL or capability overrides the denial.

Access Control Lists (ACLs) allow granting permissions to specific users or groups without modifying the standard owner/group/others permissions. The setfacl command adds an entry for carol with read access, leaving the file's mode and ownership intact. This is the appropriate method for such granular access requirements.

On typical Linux systems /etc/shadow is mode 640 with owner root and group shadow, leaving the others category with no access, which is what keeps ordinary users from reading password hashes. Those hashes are salted but still vulnerable to offline cracking if exposed, so read restriction is the key control. Direct reads happen through privileged programs, not through ordinary user access.

Octal mode 600 sets rw- for the owner and --- for both group and others. That isolates the private key to its owner while keeping read and write access intact, satisfying the stated requirement and aligning with the restrictive permissions SSH expects for private key material.

When a regular file is created, the kernel starts with a base mode of 666 (rw-rw-rw-) and applies the umask by clearing the bits specified. Umask 022 clears the write bits for group and others, leaving 644 (rw-r--r--). Thus the new file report.txt will have read and write for the owner, and read-only for group and others.