Users, groups, root, and sudo

02Identity and policy are evidence

id displays the current process's user and group information when used without arguments. A group ID, or GID, identifies a group numerically. Your names and numbers can differ from the fictional card; do not use the card as a description of your actual account.

sudo asks a configured policy to run a command as another identity, usually root unless another identity is requested. A policy is a rule deciding which requests are allowed. Belonging to a group with a familiar name does not describe every command that policy permits.

Least privilege means using only the access needed for a task. Reading an owned lab note normally needs no administrative identity. If an ordinary lab operation is denied, inspect its path and owner before considering elevation, which means requesting greater privilege. Local administrator rights also do not authorize testing someone else's system.

03Try the identity cards

The cards are fictional identity and policy records, not real id or sudo output. Use the stated ordinary user and group to explain the two tasks. You do not need to enter a password or test an administrative request.

If you have the owned Ubuntu environment, id without arguments is an optional read-only comparison. Keep its personal details private and separate from the worksheet. Without a terminal, the printed identities and policy supply every fact needed for the classification.

Users, groups and a stated policy

These fictional cards describe identities and permissions. UID means
user ID; GID means group ID. A policy decides which administrative
requests are allowed. Account and group names alone do not describe
every permitted action. Classify each task using its stated policy.

These are not actual id/sudo outputs.
Example identity: uid=1000(desk), gid=1000(desk), groups desk and club.
Activity identity: ordinary user analyst; supplemental group learners.
Policy card: analyst may read own notes without sudo; admin-approved
package installation may run as root through sudo inside owned guest.
No actual policy grants are implied by these fictional cards.
Question account A: UID 0, unrestricted Linux administrator in this model.
Question account B: named guest, ordinary unprivileged account in this model.
Which account term names the administrator: root or guest?

1. Read the activity user and group card. If using the live guest, run id without arguments and record only a private identity note; do not copy its numbers into the question at the end.
2. Classify reading an owned note and the admin-approved package task under the policy card. Expected: ordinary reading needs no elevation; package installation follows the named policy and later setup checks.
3. Choose the smallest permission needed to inspect a lab file. Expected: keep the normal user and use read-only evidence rather than elevating to make a guess work.
4. Record one unknown before any administrative action, such as which command the actual policy allows. Do not enter credentials or test sudo rights for this lesson. Stop with the note; nothing requires cleanup.

04When sudo is taught later

In a later authorized guest task, read the whole requested command before using sudo. If authentication is requested, use the guest's private credentials; terminal password input may display no characters as you type.

A denied request is a policy result to respect. Stop and use the printed alternative rather than changing policy or trying unrelated commands. This lesson makes no administrative change and does not supply a real policy grant.

05Optional challenge

Allow about ten extra minutes. Imagine an account named admin and another named student. Explain why their names alone cannot tell you which administrative commands either may run. Identify the user ID and applicable policy as evidence you would need.

06Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Current user: uid=1042(mira)
Primary group: gid=1042(mira)
Group memberships: mira, editors
A different account named admin has UID 1058 and no administrative grant is supplied.
The root administrator in this model has UID 0.
These are teaching records, not literal id output or a policy grant.

Current ordinary user: pavel, UID 1061.
Task: read an owned lab note at /home/pavel/lab/route.txt.
The path is correct and ordinary pavel access is explicitly sufficient.
No system files, installation or other user's data are part of this task.

Requester: ordinary user noa, UID 1074, member of group helpers.
The supplied policy permits noa to run one named approved report command as root.
The policy denies noa's request to run a system-editing command.
For this case, the approved report request succeeds under the stated policy.
No other permitted sudo commands or remote-testing authorization are supplied.
Do not execute a request or enter credentials; reason from these records only.

Ordinary user rafi tries to read what they believe is their owned lab note.
The supplied result says access denied.
The exact path and owner have not yet been checked.
No policy authorizes an elevated retry.

07Explain a privilege decision

Optional self-check: explain why a username, group membership, successful sudo request and local administrator identity answer different questions. Include what you would check before retrying an unexpectedly denied owned-lab action.

Review your explanation: identify the user and groups separately; use the applicable policy for each requested command and target identity; choose ordinary access when sufficient; respect a denial; and keep local privilege separate from permission to test another system. This explanation is self-reviewed.