Vizualizare sursă pentru „OS Lab 4 - Users, Groups and Permissions”

<span id="learning-outcomes"></span>
== Objectives ==

Upon completion of this lab, you will be able to:

* '''Explain''' how the kernel represents user and group identities (UIDs, GIDs, supplementary groups) and how it enforces permissions on files and directories.
* '''Demonstrate''' how privilege elevation works via effective UIDs/GIDs and setuid/setgid binaries (e.g., via <code>sudo</code>).
* '''Describe''' how user-space conventions (account databases, name service switch) map human-readable names to kernel numeric IDs.
* '''Investigate and manipulate''' these mechanisms on a Linux system to reinforce understanding of the kernel vs. user-space boundary.

<span id="introduction"></span>
== Introduction ==

In our previous lab, we explored processes as the fundamental unit of execution. Now, we investigate the security model that governs what these processes can ''do''. This lab dives into the Linux security model, carefully separating the '''kernel’s''' rigid, number-based rules from the '''user-space’s''' human-friendly conventions layered on top. Understanding this distinction is critical for system administration, security, and software development.

<span id="part-i-kernel-abstraction-the-real-security-model"></span>
== Kernel Abstraction: The Real Security Model ==

This section focuses on how the Linux kernel ''itself'' sees users and permissions. To the kernel, a “user” is just a number (a UID), and security is an algorithm.

<span id="i.a-identities-and-permission-checking"></span>
=== Identities and Permission Checking ===

<span id="background"></span>
==== Background ====

Every process running on a Linux system carries a set of numeric credentials. The most important are:

* '''User ID (UID):''' A number identifying the user who “owns” the process.
* '''Group ID (GID):''' A number identifying the process’s primary group.
* '''Supplementary Groups:''' A set of additional group IDs the process belongs to.

Likewise, every file and directory on the filesystem has metadata stored in its '''inode''', which includes:

* An '''owner UID'''
* A '''group GID'''
* '''Permission bits''' (the mode), which define access rights for three distinct categories: the '''owner''', the '''group''', and '''others'''.

These permissions are the classic <code>r</code> (read), <code>w</code> (write), and <code>x</code> (execute) triplets. Their meaning, however, depends on whether the object is a file or a directory.

{| class="wikitable"
|-
! style="text-align: left;"| Permission
! style="text-align: left;"| Meaning for a '''File'''
! style="text-align: left;"| Meaning for a '''Directory'''
|-
| style="text-align: left;"| '''<code>r</code> (read)'''
| style="text-align: left;"| Can read the contents of the file.
| style="text-align: left;"| Can list the contents of the directory (i.e., see filenames).
|-
| style="text-align: left;"| '''<code>w</code> (write)'''
| style="text-align: left;"| Can modify or truncate the file.
| style="text-align: left;"| Can create, delete, or rename files ''within'' the directory.
|-
| style="text-align: left;"| '''<code>x</code> (execute)'''
| style="text-align: left;"| Can execute the file (if it’s a program/script).
| style="text-align: left;"| Can enter (e.g., <code>cd</code>) the directory and access its inodes.
|}

'''The Permission Checking Algorithm'''

When a process (with its set of IDs) tries to access a file (with its owner/group/mode), the kernel performs a simple, sequential check:

# '''Is the process’s effective UID <code>0</code> (superuser/root)?'''
#* '''Yes:''' Access is almost always granted. Stop. (This is a simplification; mechanisms like SELinux can add further checks).
# '''Does the process’s effective UID match the file’s owner UID?'''
#* '''Yes:''' Apply the '''owner''' permission bits (<code>rwx</code>—). Access is granted or denied based ''only'' on these bits. Stop.
# '''Does any of the process’s GIDs (primary or supplementary) match the file’s group GID?'''
#* '''Yes:''' Apply the '''group''' permission bits (<code>---rwx---</code>). Access is granted or denied based ''only'' on these bits. Stop.
# '''None of the above?'''
#* Apply the '''others''' permission bits (<code>------rwx</code>). Access is granted or denied.

The '''superuser''' (UID <code>0</code>) is special. It bypasses these standard checks. This power allows it to manage the system, but it also carries significant risk.

{| class="wikitable"
|-
! style="text-align: left;"| Capability
! style="text-align: left;"| Regular User (UID &gt; 0)
! style="text-align: left;"| Superuser (UID = 0)
|-
| style="text-align: left;"| '''Read/Write Files'''
| style="text-align: left;"| Restricted by owner/group/other permissions.
| style="text-align: left;"| Can read/write ''any'' file, regardless of permissions.
|-
| style="text-align: left;"| '''Change Ownership''' (<code>chown</code>)
| style="text-align: left;"| '''Cannot''' change file ownership, not even for their own files.
| style="text-align: left;"| Can change ''any'' file’s owner and group to ''any'' user/group.
|-
| style="text-align: left;"| '''Change Permissions''' (<code>chmod</code>)
| style="text-align: left;"| Can only change permissions on files they own.
| style="text-align: left;"| Can change permissions on ''any'' file.
|-
| style="text-align: left;"| '''Bind to Privileged Ports'''
| style="text-align: left;"| Cannot bind to ports 1-1023.
| style="text-align: left;"| Can bind to any port.
|-
| style="text-align: left;"| '''System Configuration'''
| style="text-align: left;"| Limited to own user settings.
| style="text-align: left;"| Can modify kernel parameters, load modules, change system-wide settings.
|}

<span id="examples-building-blocks-i.a.1"></span>
==== Examples: File permissions ====

<syntaxhighlight lang="bash">
# Check your identity
id

# Create an empty file
touch /path/to/filename

# List file details
ls -l /path/to/filename

# Change permissions (numeric)
chmod 640 /path/to/filename

# Change ownership (root only)
sudo chown user:group /path/to/filename

# Read a file’s contents
cat /path/to/filename

# Run a command as another user
sudo -u username command

# Write text to a file as root
sudo tee /path/to/filename <<< "text"

# Remove a file (as root)
sudo rm /path/to/filename
</syntaxhighlight>

<span id="hands-on-exercise-i.a.1-file-permissions"></span>
==== Hands-on Exercise A: File Permissions ====

Let’s test this model with a file.

# First, check your own identity.
# Create a new empty file named <code>/tmp/lab4_testfile</code>.
# List the file’s details and observe that you are the owner.
# Change the file’s permissions to <code>640</code> (<code>rw-r-----</code>).
# Change the file’s owner and group to <code>root</code>. List the details again to confirm.
# As your normal user, ''attempt'' to read the file. This should fail. Document the “Permission denied” error.
# Now, try to read the file as the <code>nobody</code> user. This should also fail.
# Finally, demonstrate root’s power:
#* Use <code>sudo</code> to write the text “hello from root” into the file, bypassing its permissions.
#* Read the file using <code>sudo</code> to confirm the text is there.
#* Use <code>sudo</code> to change the file’s permissions to <code>600</code> (<code>rw-------</code>).
#* List the file’s details one last time.
# Clean up by removing the file as root.

<span id="examples-building-blocks-i.a.2"></span>
==== Examples: Directory permissions ====

<syntaxhighlight lang="bash">
# Create a directory
mkdir /path/to/dirname

# Change permissions (symbolic)
chmod u-x,g+r /path/to/dirname

# List the directory itself (not its contents)
ls -ld /path/to/dirname

# Enter the directory
cd /path/to/dirname

# Remove a directory and all its contents
rm -r /path/to/dirname
</syntaxhighlight>


<span id="hands-on-exercise-i.a.2-directory-permissions"></span>
==== Hands-on Exercise B: Directory Permissions ====

Directory permissions are different. Let’s test the <code>x</code> (execute) bit.

# Create a new directory named <code>/tmp/lab4_dir</code> and a file named <code>secretfile</code> inside it.
# Set the directory’s permissions to <code>700</code> (<code>rwx------</code>). List the directory’s details to confirm.
# Verify you can list the directory’s contents and read the <code>secretfile</code> inside it.
# Now, remove ''only'' the '''execute (<code>x</code>) bit''' for the owner of <code>/tmp/lab4_dir</code>.
# Try to <code>cd</code> into the directory. This will fail.
# Try to list the directory’s contents. This will also fail.
# Try to read the <code>secretfile</code> using its full path. This will also fail, as you can’t traverse the directory.
# Now, restore the execute bit (<code>u+x</code>) but remove the read bit (<code>u-r</code>) for the owner of <code>/tmp/lab4_dir</code>. Its permissions should be <code>--wx------</code>.
# Try to list the directory’s contents. This will fail.
# Try to <code>cd</code> into the directory. This will ''succeed''.
# Once inside, try to read the <code>secretfile</code> (which you know exists). This will ''succeed''.
# Return to the parent directory (<code>cd ..</code>).
# Clean up: To remove the directory, you must first restore permissions (e.g., <code>700</code>) so you can delete its contents, then remove the directory and its contents.

<span id="i.b-privilege-changes-and-sudo"></span>
=== Privilege Changes and <code>sudo</code> ===

<span id="background-1"></span>
==== Background ====

The permission model is static, but a process’s identity can change. The kernel tracks multiple UIDs for each process:

* '''Real UID (ruid):''' The UID of the user who ''launched'' the process. This rarely changes.
* '''Effective UID (euid):''' The UID the kernel ''uses for permission checks''. This is the ID that matters for file access.

Normally, <code>ruid == euid</code>. However, a special permission bit on an executable file, the '''setuid''' bit, can change this.

* '''Setuid (Set User ID):''' If an executable file has this bit set (shown as <code>s</code> instead of <code>x</code> in the ''owner’s'' execute-bit position, e.g., <code>-rwsr-xr-x</code>), when any user executes it, the kernel sets the new process’s '''effective UID (euid)''' to be the '''UID of the file’s owner'''.

The <code>sudo</code> command is the classic example:

# The <code>sudo</code> binary (<code>/usr/bin/sudo</code>) is owned by <code>root</code>.
# It has the <code>setuid</code> bit set.
# When a normal user (e.g., <code>student</code>, <code>ruid=1001</code>) runs <code>sudo</code>, the kernel starts the <code>sudo</code> process with <code>ruid=1001</code> but <code>euid=0</code> (root).
# Now running with root’s ''effective'' permissions, the <code>sudo</code> process is allowed to read its configuration file, <code>/etc/sudoers</code>.
# It checks <code>/etc/sudoers</code> to see if the ''real'' user (<code>student</code>) is allowed to perform the requested action.
# If allowed, <code>sudo</code> (still running as <code>euid=0</code>) uses its power to launch the target command (e.g., <code>apt update</code>) as <code>root</code> (or as another specified user).

This mechanism is also used by utilities like <code>passwd</code> (which must run as root to edit <code>/etc/shadow</code>) and <code>login</code>/<code>sshd</code> (which start as root to authenticate users, then ''drop'' privileges to become the user who just logged in).

A parallel '''setgid (Set Group ID)''' bit exists, which changes the process’s '''effective GID (egid)''' to the file’s group. This is less common today, as modern systems tend to give users more flexible supplementary groups.

<span id="examples-building-blocks-i.b"></span>
==== Examples: Sudo and su ====

<syntaxhighlight lang="bash">
# List file permissions
ls -l /path/to/binary

# Run a command as another user
sudo -u username id

# Run a command as root (prompts for root password -- this will usually not work, because root's password is usually not set)
su -c 'id'

# Run a command as another user (prompts for that user's password)
su - username -c 'id'

# Create a script
echo '#!/bin/bash' > script.sh

# Append to the script
echo 'echo "My eUID is: $(id -u -n)"' >> script.sh

# Make the script executable
chmod +x script.sh

# Set the setuid bit (root only)
sudo chmod u+s script.sh
</syntaxhighlight>

<span id="hands-on-exercise-i.b.1-investigating-sudo-and-su"></span>
==== Hands-on Exercise C: Investigating <code>sudo</code> and <code>su</code> ====

# View the permissions and ownership of the <code>sudo</code> binary (likely <code>/usr/bin/sudo</code>). Note the <code>s</code> bit.
# View the permissions of the <code>su</code> binary (likely <code>/bin/su</code>). Note if it is also setuid root.
# Use <code>sudo</code> to run the <code>id</code> command as the <code>nobody</code> user.
# Run <code>id</code> as your normal user and compare the output.
# Use <code>su</code> to ''attempt'' to run the <code>id</code> command, first as <code>root</code> and then as <code>nobody</code>.
# Observe the password prompts. Unlike <code>sudo</code> (which asks for ''your'' password), <code>su</code> asks for the ''target user’s'' password.

<span id="hands-on-exercise-i.b.2-setuid-script-optional"></span>
==== Hands-on Exercise O1: Setuid Script (Optional) ====

'''(Optional, may be blocked by security policies)''' Attempt to create a setuid script. Note that for security reasons, most modern systems ''ignore'' the setuid bit on shell scripts. This only works on compiled binaries.

# Create a simple shell script at <code>/tmp/lab4_script.sh</code> that prints the process’s effective and real user IDs.
# Make the script executable.
# As root, change the script’s owner to <code>root</code> and set its <code>setuid</code> bit.
# List the script’s permissions to confirm the <code>s</code> is present.
# Run the script as your normal, non-root user.
# Observe the output: does the eUID show ‘root’ or your user? On most modern systems, the setuid bit will be ignored for scripts.
# Clean up the script file.

<span id="i.c-additional-reading-optional"></span>
=== Additional Reading (Optional) ===

This lab covers the standard security model. For further study, explore these advanced topics that refine or alter this model:

* '''SUID and FSUID:''' Aside from the <code>ruid</code> and <code>euid</code>, each process has two more numeric ids. The <code>fsuid</code> (filesystem UID) is an internal Linux mechanism that allows a privileged process (like an NFS server) to perform filesystem operations as another user without fully changing its <code>euid</code>. The <code>fsuid</code> (filesystem UID) is an internal Linux mechanism that allows a privileged process (like an NFS server) to perform filesystem operations as another user without fully changing its <code>euid</code>; the <code>suid</code> (saved set-user-ID) stores the previous <code>euid</code> so a process (e.g., a setuid program) can drop privileges and later regain them safely. Similarly, there is an <code>fsgid</code> and <code>sgid</code>.
* '''ACLs (Access Control Lists):''' <code>getfacl</code> and <code>setfacl</code> commands manage permissions for ''specific'' additional users and groups, going beyond the simple owner/group/other model.
* '''SELinux and AppArmor:''' optional kernel modules that provide stricter access control rules. AppArmor specifies restricitons for particular applications and is easier to slot into existing configurations; it is used by Ubuntu. SELinux provides very complex fine-grain control, but can break deployments which do not take it into account; it is used by Red Hat Enterprise Linux.
* '''Capabilities:''' A way to break root’s “all-or-nothing” power into discrete privileges (e.g., <code>CAP_NET_BIND_SERVICE</code> allows binding to privileged ports ''without'' granting full root).
* '''User Namespaces:''' A key container technology that remaps UIDs, allowing a process to ''think'' it’s UID 0 inside its namespace while being a normal UID on the host.

<span id="part-ii-user-space-convention-the-human-layer"></span>
== User-Space Convention: The Human Layer ==

The kernel only cares about numbers. This section covers the user-space tools and files that map human-readable names like <code>root</code> or <code>student</code> to the kernel’s numeric UIDs and GIDs.

<span id="ii.a-accounts-and-the-password-database"></span>
=== Accounts and the Password Database ===

<span id="background-2"></span>
==== Background ====

The kernel knows you as UID 1001, not as <code>student</code>. The mapping from name to number (and other metadata) is handled in user-space, primarily by a set of text files in <code>/etc</code>.

* <code>/etc/passwd</code>: The main user database. It is '''world-readable''' and contains one line per user, with fields separated by colons (<code>:</code>). <code>username:x:UID:GID:Full Name:/home/dir:/shell</code>
** <code>username</code>: Your login name.
** <code>x</code>: A placeholder. In the past, the encrypted password hash was here.
** <code>UID</code>: The all-important '''User ID''' number. This is what the kernel uses.
** <code>GID</code>: The user’s primary '''Group ID''' number.
** '''Comment (GECOS):''' This is a comment field, historically called the GECOS (General Electric Comprehensive Operating System) field. It is a comma-separated list that ''conventionally'' stores the following fields. Most systems today just use the first part for the display name.
**# User’s Full Name (e.g., <code>John Doe</code>)
**# Room Number
**# Work Phone
**# Home Phone
**# Other contact info
** <code>/home/dir</code>: The user’s home directory.
** <code>/shell</code>: The user’s default login shell (e.g., <code>/bin/bash</code>).
* <code>/etc/shadow</code>: Because <code>/etc/passwd</code> must be world-readable (so <code>ls -l</code> can show names instead of numbers), the sensitive password hashes were moved here. This file is '''only readable by root'''. <code>username:password_hash:last_change:etc...</code>
* <code>/etc/group</code>: The group database, also world-readable. <code>groupname:x:GID:member_list</code>
** <code>groupname</code>: The human-readable group name.
** <code>GID</code>: The numeric '''Group ID'''.
** <code>member_list</code>: A comma-separated list of ''additional'' users who are part of this group (for their supplementary groups).

<span id="examples-building-blocks-ii.a.1"></span>

==== Examples: Inspecting Account Databases ====

<syntaxhighlight lang="bash">
# View the top of a file (first 10 lines)
head -n 10 /path/to/file

# View a file as root
sudo cat /path/to/file

# Query the NSS database for a user
getent passwd <username>

# Query the NSS database for a group
getent group <groupname>
</syntaxhighlight>

<span id="hands-on-exercise-ii.a.1-inspecting-account-databases"></span>
==== Hands-on Exercise D: Inspecting Account Databases ====

# Display the first 10 lines of the <code>/etc/passwd</code> user database.
# Attempt to display the first 5 lines of <code>/etc/shadow</code>. This will fail.
# Use <code>sudo</code> to display the first 5 lines of <code>/etc/shadow</code> to prove root can read it.
# Display the first 10 lines of the <code>/etc/group</code> database.
# Use the <code>getent</code> command to query the <code>passwd</code> database for the <code>root</code> user and for your own user (using the <code>$USER</code> variable).
# Use <code>getent</code> to query the <code>group</code> database for the <code>sudo</code> group and for your own primary group (which you can find from the <code>id</code> command).

<span id="examples-building-blocks-ii.a.2"></span>
==== Examples: Modifying GECOS and Passwords ====

<syntaxhighlight lang="bash">
# View user GECOS info
finger <username>

# Change your GECOS info interactively (current user)
chfn

# Change your password (current user)
passwd

# Find a user’s line in /etc/passwd
grep "^<username>:" /etc/passwd
</syntaxhighlight>

<span id="hands-on-exercise-ii.a.2-modifying-gecos-and-passwords"></span>
==== Hands-on Exercise E: Modifying GECOS and Passwords ====

# Use the <code>finger</code> command to view your user’s GECOS information.
# Use the <code>chfn</code> command to interactively change your GECOS information (Full Name, Room Number, etc.). You may be prompted for your password.
# Run <code>finger</code> again to see the changes have been applied.
# Check your entry in the <code>/etc/passwd</code> file (using <code>getent</code> or <code>grep</code>) to see how the GECOS field (the 5th field) was updated.
# Use the <code>passwd</code> command to change your password. This command securely updates the <code>/etc/shadow</code> file.

<span id="ii.b-name-service-switch-nss"></span>
=== Name Service Switch (NSS) ===

<span id="background-3"></span>
==== Background ====

Storing all users in local <code>/etc</code> files doesn’t scale in a large organization. What if you want to log in to 1,000 different machines with the same username and password?

The '''Name Service Switch (NSS)''' is a user-space (specifically, C library) mechanism that makes this possible. It allows system functions (like <code>getpwnam()</code> which “gets password-entry-by-name”) to look for information in multiple sources.

The configuration file is <code>/etc/nsswitch.conf</code>. It contains lines like:

<code>passwd:    files systemd ldap</code> <code>group:     files sss</code>

This tells the system: “When looking up a user (<code>passwd</code>), first check local <code>files</code> (<code>/etc/passwd</code>), then ask the <code>systemd</code> user database, and if still not found, query the <code>ldap</code> server.”

This system is powerful because it allows a a system to pull user/group info from network services like '''LDAP''', '''NIS''', or '''SSS''' (System Security Services Daemon) without changing any kernel behavior. The kernel ''still'' only receives and operates on the final numeric UID/GID.

<span id="examples-building-blocks-ii.b.1"></span>
==== Examples: Inspecting NSS ====

<syntaxhighlight lang="bash">
# Print the nsswitch configuration
cat /etc/nsswitch.conf

# Query the NSS database for a specific user
getent passwd <username>
</syntaxhighlight>

<span id="hands-on-exercise-ii.b.1-inspecting-nss"></span>
==== Hands-on Exercise F: Inspecting NSS ====

<ol style="list-style-type: decimal;">
<li><p>Display the lines from <code>/etc/nsswitch.conf</code> that configure the <code>passwd</code> and <code>group</code> databases (the lines starting with <code>passwd:</code> and <code>group:</code>).</p></li>
<li><p>Test the lookup system by using <code>getent</code> to resolve the <code>nobody</code> user and the <code>nogroup</code> group.</p></li>
<li><p>'''(Optional, use with extreme care)''' As root, edit <code>/etc/nsswitch.conf</code> (e.g., <code>sudo nano /etc/nsswitch.conf</code>). Put a <code>#</code> at the beginning of the <code>group:</code> line to comment it out, and add a new line <code>group: sss</code> (a service that is likely not running). Save the file.</p>
<p>Now, try to resolve group names using <code>getent group sudo</code> and <code>ls -l /</code>. Observe that names may now show up as numbers.</p>
<p>'''IMMEDIATELY''' restore <code>/etc/nsswitch.conf</code> to its original state and verify <code>ls -l</code> works again. This exercise demonstrates how critical this user-space configuration is for the “human-friendly” layer.</p></li></ol>

<span id="examples-building-blocks-ii.b.2"></span>
==== Examples: Creating Users and Groups ====

<syntaxhighlight lang="bash">
# Add a group
sudo groupadd <groupname>

# Add a user with options (home dir, primary group, supplementary group, login shell)
sudo useradd -m -g <primary_group> -G <suppl_group> -s /bin/bash <username>

# Set a user’s password
sudo passwd <username>

# Switch to a user (login shell)
su - <username>

# Delete a user and their home directory
sudo userdel -r <username>

# Delete a group
sudo groupdel <groupname>

# Check the end of the /etc/group file (last 3 lines)
tail -n 3 /etc/group
</syntaxhighlight>

<span id="hands-on-exercise-ii.b.2-creating-users-and-groups"></span>
==== Hands-on Exercise G: Creating Users and Groups ====

Let’s use the standard user-space tools to create a new user and group. These tools automatically update the <code>/etc/passwd</code>, <code>/etc/shadow</code>, and <code>/etc/group</code> files.

# As root, create a new group named <code>labtesters</code>.
# Verify the group was added by checking the end of the <code>/etc/group</code> file and by using <code>getent</code>.
# As root, create a new user named <code>testuser</code>. When creating them, specify:
#* Their primary group should be <code>labtesters</code>.
#* They should be added to the <code>sudo</code> supplementary group.
#* Their home directory should be created (<code>-m</code>).
#* Their login shell should be <code>/bin/bash</code>.
# Verify the user was created by querying the <code>passwd</code> and <code>shadow</code> (with <code>sudo</code>) databases using <code>getent</code>.
# Check the <code>labtesters</code> and <code>sudo</code> group entries (using <code>getent</code>) to confirm <code>testuser</code>’s membership.
# Set a password for <code>testuser</code> so they can log in.
# Use <code>su</code> to start a new login shell as <code>testuser</code>.
# Once logged in as <code>testuser</code>, run <code>id</code> to check your identity and <code>pwd</code> to see your home directory.
# <code>exit</code> the <code>testuser</code>’s shell to return to your original session.
# Clean up: as root, delete the <code>testuser</code> (making sure to remove their home directory) and delete the <code>labtesters</code> group.
# Verify they are gone using <code>getent</code>.

<span id="part-iii-tool-summary"></span>
== Tool Summary ==

This lab uses two distinct categories of tools: those that interact directly with the kernel’s security model, and those that manage the user-space databases.

<span id="kernel-level-privilege-tools"></span>
=== Kernel-Level &amp; Privilege Tools ===

These commands directly manipulate kernel-level concepts (file ownership, process UIDs) or are used for privilege escalation.

{| class="wikitable"
|-
! style="text-align: left;"| Command
! style="text-align: left;"| Description
! style="text-align: left;"| Common Flags
|-
| style="text-align: left;"| '''<code>chown</code>'''
| style="text-align: left;"| '''Ch'''ange '''own'''er. Changes the UID and GID owner of a file/directory. ''Requires kernel-level privilege (e.g., eUID=0) to change owner to someone else.''
| style="text-align: left;"| <code>-R</code>: Recursive<br><code>user:group</code>: Set both user and group
|-
| style="text-align: left;"| '''<code>chgrp</code>'''
| style="text-align: left;"| '''Ch'''ange '''gr'''ou'''p'''. Changes the GID owner of a file/directory. ''You must be the owner of the file AND a member of the target group.''
| style="text-align: left;"| <code>-R</code>: Recursive
|-
| style="text-align: left;"| '''<code>id</code>'''
| style="text-align: left;"| Display process identity (UID, GID, groups).
| style="text-align: left;"| <code>-u</code>: Show UID only<br><code>-g</code>: Show GID only<br><code>-n</code>: Show name instead of number
|-
| style="text-align: left;"| '''<code>sudo</code>'''
| style="text-align: left;"| '''S'''ubstitute '''u'''ser '''do'''. Executes a command as another user (default: root) based on <code>/etc/sudoers</code> rules. Uses setuid.
| style="text-align: left;"| <code>-u user</code>: Run as <code>user</code><br><code>-i</code>: Start a root login shell<br><code>-l</code>: List allowed commands
|-
| style="text-align: left;"| '''<code>su</code>'''
| style="text-align: left;"| '''S'''ubstitute '''u'''ser. Switches to another user account (default: root). Authenticates using the ''target'' user’s password.
| style="text-align: left;"| <code>-</code> or <code>-l</code>: Start a full login shell<br><code>-c 'cmd'</code>: Run a single command
|}

<span id="user-space-account-database-tools"></span>
=== User-Space Account Database Tools ===

These commands read from or write to the user-space databases (e.g., <code>/etc/passwd</code>, <code>/etc/shadow</code>, <code>/etc/group</code>), which are then interpreted by NSS.

{| class="wikitable"
|-
! style="text-align: left;"| Command
! style="text-align: left;"| Description
! style="text-align: left;"| Common Flags
|-
| style="text-align: left;"| '''<code>passwd</code>'''
| style="text-align: left;"| Change a user’s password. Securely updates <code>/etc/shadow</code>.
| style="text-align: left;"| <code>[username]</code>: Change password for <code>username</code> (root only)<br><code>-l</code>: Lock account<br><code>-u</code>: Unlock account
|-
| style="text-align: left;"| '''<code>getent</code>'''
| style="text-align: left;"| '''Get ent'''ries from NSS databases. The correct way to look up users/groups.
| style="text-align: left;"| <code>passwd [user]</code>: Look up user<br><code>group [group]</code>: Look up group<br><code>shadow [user]</code>: Look up shadow entry
|-
| style="text-align: left;"| '''<code>chfn</code>'''
| style="text-align: left;"| '''Ch'''ange '''f'''i'''n'''ger. Modifies the GECOS field in <code>/etc/passwd</code>.
| style="text-align: left;"| <code>[username]</code>: Modify for <code>username</code> (root only)
|-
| style="text-align: left;"| '''<code>finger</code>'''
| style="text-align: left;"| Displays user information, primarily by parsing the GECOS field.
| style="text-align: left;"| <code>[username]</code>: Show info for <code>username</code>
|-
| style="text-align: left;"| '''<code>useradd</code>'''
| style="text-align: left;"| Creates a new user account. Updates <code>/etc/passwd</code>, <code>/etc/shadow</code>, <code>/etc/group</code>.
| style="text-align: left;"| <code>-m</code>: Create home directory<br><code>-g group</code>: Set primary group<br><code>-G groups</code>: Set supplementary groups<br><code>-s shell</code>: Set login shell
|-
| style="text-align: left;"| '''<code>groupadd</code>'''
| style="text-align: left;"| Creates a new group. Updates <code>/etc/group</code>.
| style="text-align: left;"| <code>[groupname]</code>
|}

<span id="deliverables-and-assessment"></span>
== Deliverables and Assessment ==

Submit a single document containing:

# '''Command Output:''' Screenshots of command output for each non-optional hands-on exercise (A-G).
# '''Conclusion Questions:''' Short written answers to the “Conclusion Questions” below.

<span id="conclusion-questions"></span>

== Conclusion Questions ==

Please answer the following summary questions based on the lab’s content.

# Explain the kernel’s permission checking algorithm. If a file <code>/data/report.txt</code> is owned by <code>root:webdev</code> and has permissions <code>640</code> (<code>rw-r-----</code>), can the user <code>student</code> (who is a member of the <code>webdev</code> group) ''read'' the file? Why or why not?
# Why was the sensitive password hash moved from the world-readable <code>/etc/passwd</code> to the root-only-readable <code>/etc/shadow</code>? What kernel-level permission difference enables this security?
# Explain the relationship between the user-space tool <code>useradd</code>, the file <code>/etc/passwd</code>, the Name Service Switch (NSS), and the kernel’s UID-based permission checks. How do they all interact when you run <code>ls -l</code>?
# What would happen if you (as root) manually edited <code>/etc/passwd</code> and changed your user’s UID from <code>1001</code> to <code>5001</code>, but did ''not'' change the ownership of any files in your home directory (which are all still owned by kernel UID <code>1001</code>)? What specific problems would you face at your next login?