Users and groups

Names are convenient; IDs determine ownership

Linux uses numeric user and group IDs. Human-friendly names are resolved through configured identity sources. A login session has a user ID, a primary group, and supplementary groups. A service can run under a different account from the person deploying it.

Inside the disposable VM, inspect your current identity:

id
getent passwd "$(id -un)"
getent group "$(id -gn)"
ls -ld "$HOME"

Read the account's home directory and shell fields without assuming every account is interactive. System service accounts often have no usable login shell, but that alone does not define all their privileges.

Read the account record

An illustrative getent passwd line is:

learner:x:1000:1000:Learning account:/home/learner:/bin/bash

Its colon-separated fields are username, password placeholder, user ID (UID), primary group ID (GID), descriptive information, home directory, and login shell. x does not reveal a password; local password hashes usually live in the protected shadow database. getent asks the machine's configured account sources, which may include more than local /etc/passwd.

An id result such as uid=1000(learner) gid=1000(learner) groups=1000(learner),27(sudo) says the process has one UID, a primary group, and supplementary membership in sudo. Membership only has meaning through the file permissions or policy that uses it. The number 1000 is an example, not a requirement.

Compare name and numeric listings of your home:

ls -ld "$HOME"
ls -ldn "$HOME"
id -u
id -g

The same ownership is presented as names or numbers. A file copied between systems can retain a numeric ID that maps to a different name, so a familiar username is not enough to infer who owns all transferred files.

A service account is intended to run software rather than provide a person's interactive login. It often has a non-login shell and a dedicated data directory. A non-login shell discourages interactive sessions; it does not prevent an administrator or service manager from running a process as that account. UID 0 and configured privilege mechanisms deserve separate attention.

Group changes affect sessions

Changing an account's supplementary groups does not rewrite credentials inside every existing process. A new login session usually obtains the updated membership. Compare id in the actual session performing the operation, not just the account database entry.

For a shared configuration directory, decide who should read, write, and search it before choosing a group or ACL. Group ownership and a directory's setgid bit can help new entries inherit the directory group, but file modes and default ACLs still matter. One group membership is not a universal permission grant.

Apply the idea to a service

Inspect a service's configured User= and Group= and compare them with the owner and modes of its configuration. Write an access matrix with rows for administrator, deployment account, and runtime account. Grant runtime write access only to locations the process needs to change.

This bite does not create accounts or alter memberships. The access lab uses an existing disposable VM account so the exercise has a clear owner and recovery route.

Work a personal-site access decision

Suppose site-reader is the runtime account and site-editor prepares content. The runtime needs to read public/index.html and search its parent directories. It does not need to edit source, deploy keys, or unrelated notes. A useful proposed matrix is:

This is a reasoning exercise; do not create these accounts yet. For any actual service, compare User=/Group= with its current process credentials. An old running service can retain its old group set even after the account database changes.

An administrator adding a supplementary group should understand usermod -aG: without -a, -G replaces the supplementary group list. A new login or restarted process may be required to obtain new credentials. This course's core lab does not need membership changes, so inspecting the existing identity is enough.

Question: a file is group-readable to web, but your current id does not include web. Does a database change alone prove this session can read it? No. Check the credentials of the process actually attempting the read, then all path permissions. Next, distinguish that ordinary access from deliberate privilege through sudo.

Check and revise

Why does reading a file successfully with sudo cat fail to prove the service can read it? It tests a different identity. Revision: account record → active process credentials → object ownership/mode → additional access controls.

Sources

Primary references: Linux credentials↗; GNU id↗.