Linux Security / Basic: identity, resources, and evidence / Lesson 2

Understand Linux identity and credential scope

Separate names, numeric ids, process credentials, group context, and authentication evidence.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain why a username string is not authority by itself.
Use scoped synthetic identities without reading or changing host accounts.

Distinguish a name from the identity used for a check

User and group names are human-facing mappings, while many kernel permission checks use numeric credentials and relevant process state. A name can map differently across systems or namespaces, and equal text does not prove equal authority. Do not accept a request field named user as a trusted process identity. A real application obtains subject context through its reviewed authentication and authorization boundary, while the operating system enforces its own resource rules. This lesson uses fixed invented mappings only and does not read account databases, environment identity, or current host credentials.

Include the identity domain in comparisons

The first program shows the same numeric uid in two fictional identity domains. The composite domain/id keys differ even though the number matches. This illustrates a scope question rather than implementing Linux user-namespace mappings. Actual namespace translation, filesystem ownership views, and host authority require platform-specific interpretation. Preserve the domain and source of every identity fact. Reusing a familiar uid such as an application service number across systems does not make the accounts interchangeable or establish the same person. A clear identity model prevents accidental cross-system joins and overly broad grants.

python Compare invented domain-scoped identities

a = {"domain":"host-lab", "uid":1200, "name":"reporter"}
b = {"domain":"container-lab", "uid":1200, "name":"reporter"}
identity = lambda row: (row["domain"], row["uid"])
assert a["uid"] == b["uid"]
assert a["name"] == b["name"]
assert identity(a) != identity(b)
print("equal labels and numbers remain domain-scoped")

Expected output

equal labels and numbers remain domain-scoped

The complete program compares dictionaries and performs no uid lookup or namespace operation. The domains are classroom labels rather than actual kernel mappings. No account, group, permission, or process credential is changed.

Keep the relevant credential fields distinct

Linux distinguishes real, effective, saved, and filesystem-related user/group credentials, with supplementary groups and capabilities also affecting authority. Do not reduce all checks to one username column. Filesystem access commonly depends on filesystem ids, which normally track effective ids but have their own semantics. The second program selects a declared supplementary-group relationship for a fictional task; it is not a complete access-control engine. A real process can retain existing credentials after an account database change until the relevant lifecycle transition occurs. Record the actual context rather than assuming every session immediately receives a new group assignment.

python Check synthetic group membership without host lookups

subject = {"uid":1200, "primaryGid":1200, "supplementaryGids":{1300, 1400}}
required_group = 1300
groups = {subject["primaryGid"]} | subject["supplementaryGids"]
assert required_group in groups
assert 1500 not in groups
assert subject["uid"] == 1200
print("declared primary and supplementary group membership checked")

Expected output

declared primary and supplementary group membership checked

The complete program computes membership over fixed numeric sets. It authenticates no user, checks no real file, and reads no group database. Membership alone does not establish application permission or actual kernel access.

Separate authentication, authorization, and session lifecycle

Authentication establishes a subject under a chosen mechanism; authorization decides permitted actions; session and process lifecycle determine which established facts remain in use. A public key, password policy, group entry, and application role have different purposes. Avoid implementing a homemade credential system in a lesson. Use supported platform integrations in an approved real design and verify their failure behavior separately. A disabled account flag does not automatically prove that every existing process, remote session, token, or delegated capability has ended. The intended revocation effect must be explicitly defined and observed at the relevant boundary.

Review authority with source and time context

For a sensitive operation, record where the trusted subject came from, which credential fields matter, how groups or roles were obtained, and when changes take effect. Test allowed, missing, wrong-domain, and stale-context cases with invented fixtures. Avoid using actual usernames or credentials from this host as convenient examples. The local calculations support identity reasoning only. Real account management, PAM, directory integration, process transitions, and revocation remain unexecuted. A reviewable conclusion explains the specific relationship established without treating a successful dictionary comparison as proof of a protected Linux deployment.

Common errors and fixes

A username parameter becomes trusted authority

Why it happens: Client text is confused with established subject context.
How to fix it: Obtain identity through the reviewed boundary.
Prevent it next time: Separate request claims and trusted credential facts.

Equal uid values identify the same account everywhere

Why it happens: Identity domains and mappings are omitted.
How to fix it: Include relevant domain and source context.
Prevent it next time: Test deliberate same-number different-domain cases.

A group edit is assumed to update every running process

Why it happens: Account records and process credential lifecycle are conflated.
How to fix it: Define and verify when the new context applies.
Prevent it next time: Keep session and revocation assumptions explicit.

Check your understanding

1. Two systems show reporter with uid 1200. Is one identity established?

Show worked solution

No. Record domain, mapping source, and the authority relevant to the resource. Equal names and numbers are insufficient across systems or namespaces. The classroom example deliberately distinguishes two domains and performs no actual identity translation or account lookup.

2. A process lacks a newly assigned group. What should the diagnostic model distinguish?