Introduction
Security tools and evidence files run under user identities. Understanding those identities helps you choose the permissions needed for a task without making every file accessible to every account.
You will create a practice account inside Kali, assign it a private case directory, and test both allowed and denied access. This lab covers local users and file permissions; processes and logs have their own later lab.
Identify Users and Create a Practice Account
In this step, you will distinguish ordinary-user identity from administrator authority and create a separate local account inside Kali.
Enter the prepared Kali shell, then select the shared workspace:
kali
cd /home/labex/project
id shows your numeric user ID (UID), primary group ID (GID), and group membership:
id
The username is kali; the numeric IDs can vary between environments. UID 0 identifies root, the administrator. Your ordinary account has a nonzero UID.
sudo runs an authorized command with higher privileges. This training container permits the Kali learner to use it without a password. This permission is local to the container; it is not a reason to run every command as root. Ask root to identify itself for one command:
sudo whoami
The output is root. The elevation ends when that command finishes:
whoami
The output is still kali.
A local account has a name, UID, group, home directory, and login shell. useradd creates an account and requires administrator authority. --create-home creates its home directory, --user-group creates a matching primary group, and --shell /bin/bash chooses Bash as its shell:
sudo useradd --create-home --user-group --shell /bin/bash practice-analyst
Do this once in a fresh lab; an existing-account message means the account is already present. No password or SSH access is needed for this exercise. Inspect the new identity by passing its name to id:
id practice-analyst
The output names practice-analyst as both user and primary group. Its UID should differ from kali and root.
Assign Ownership and Private Permissions
In this step, you will create a case directory, transfer its ownership, and limit access to its assigned account.
Return to the shared workspace:
cd /home/labex/project
Create a directory as your ordinary user:
mkdir case-files
ls -ld describes the directory itself: -l requests detailed output, while -d prevents listing its contents instead:
ls -ld case-files
The output includes permission characters, an owner, and a group. Initially the owner is kali. The first character d means directory. The next nine positions form three groups of read (r), write (w), and execute (x) bits for owner, group, and others. On a directory, read lists names, write changes entries, and execute permits traversal to entries.
chown changes ownership. The user:group form assigns both the owner and group; administrator authority is needed to transfer ownership to another account:
sudo chown practice-analyst:practice-analyst case-files
chmod changes permissions. In numeric form, read is 4, write is 2, and execute is 1. The sum 7 gives all three; 0 gives none. Mode 700 gives the owner full access and grants no directory access to group or others:
sudo chmod 700 case-files
ls -ld case-files
The beginning should read drwx------, and owner and group should be practice-analyst. Dates and numeric sizes may vary. Ownership chooses which account receives the owner permissions; the mode then defines the access granted to each category.
Test Access as the Intended Account
In this step, you will check access using real user identities instead of relying only on a permission listing.
sudo -u NAME runs a command as the named user rather than root. Use the case owner to create a file in its private directory:
sudo -u practice-analyst touch /home/labex/project/case-files/checked.txt
No output is expected. Inspect the result as the same account:
sudo -u practice-analyst ls -l /home/labex/project/case-files
The empty checked.txt file should be owned by practice-analyst. Its creation proves that this account can traverse and write to the directory.
The ordinary Kali account should not have that access. The next command is expected to fail with a permission-denied message, demonstrating the restriction. Continue after the error:
ls /home/labex/project/case-files
Root can still inspect the directory through an explicitly authorized command:
sudo ls /home/labex/project/case-files
You should see checked.txt. Private permissions restrict ordinary accounts; root retains administrative authority. Keep using kali for normal work and elevate only the particular operation that requires it. None of these commands changes the host learner account or the way LabEx connects to the VM.
Summary
You inspected user identities, used sudo for specific administrative actions, created an account, and assigned directory ownership and permissions. You confirmed that the intended account could work while another ordinary account was denied access.
