Linux IAM: Users, Groups, and Permission Boundaries



IAM • Linux • Users/Groups • Authorization • chmod

Linux IAM: Users, Groups, and Permission Boundaries

Built and enforced local access control on Linux: I created users + groups, assigned group membership, then
used directory permissions to prove a core IAM truth — authentication doesn’t automatically grant access.
Authorization boundaries (least privilege) determine what an authenticated identity can actually do.

← Back to IAM Hub
Status: ✅ Completed
Stack: Ubuntu Linux, local users/groups, chmod

Overview (My POV)

This lab wasn’t “learn Linux commands.” I treated Linux as an IAM system: identities are users/groups,
authorization is permission bits, and enforcement happens at the filesystem boundary. I built a simple
role model (HR group) and demonstrated a before/after proof that an authenticated user can still be denied
by authorization.

Control
AuthN vs AuthZ
Chokepoint
IAM (host-level)
Proof
Allowed → Denied test

What I Did

  • Created a group (HR) as an authorization primitive (RBAC-style access).
  • Provisioned users (jenny, joe) and assigned them to the group.
  • Observed baseline directory access (why defaults can be too permissive).
  • Hardened permissions to enforce least privilege (chmod).
  • Verified “before/after” access outcomes (allowed → denied).
  • Tuned permissions to allow read/traverse but deny writes (granular authorization).

What This Proves

AuthN proves identity. AuthZ determines access. Linux enforces that boundary locally.

Jenny can successfully log in (authentication), but still gets blocked from Joe’s directory after hardening
(authorization). That’s the same control logic used by cloud IAM and enterprise access control — just enforced
at the OS boundary instead of a cloud control plane.

  • Identity: users + groups
  • Authorization: permission bits (rwx for user/group/others)
  • Enforcement: filesystem/kernel denies access

Permission Logic (directory)

Directory permissions matter differently than files:

x = traverse/enter directory
r = list directory contents
w = create/delete/rename entries (where allowed)

So removing "others execute" blocks outsiders from entering a folder,
even if they are authenticated users on the system.

That’s least privilege as a boundary: the system denies by default unless permissions explicitly allow it.

Proof Gallery (Minimal Set)

Created HR group and verified it exists
1) Created the HR group and verified it exists (getent group HR) — authorization primitive.
Created users and added them to HR group
2) Provisioned jenny and joe and assigned group membership (groups jenny joe) — identity + RBAC mapping.
Before hardening: access was possible
3) Before hardening: Jenny could traverse into Joe’s directory — baseline access was too permissive.
Hardened directory permissions with chmod
4) Hardened the boundary by removing “others execute” (chmod o-x joe) — blocks directory traversal.
After hardening: permission denied
5) After hardening: Jenny was denied (Permission denied) despite being authenticated — AuthN ≠ AuthZ.
Read/traverse allowed but write denied
6) Tuned permissions to allow read/traverse but deny writes — granular authorization (visibility without modification).

Result

  • Created and assigned identities via users + groups.
  • Enforced least privilege at the OS boundary with chmod.
  • Demonstrated a real authorization denial after successful authentication.
  • Implemented a read/traverse model while preventing write operations.

Why This Makes Me Valuable

Cloud IAM is just one expression of access control. I understand the underlying model across layers:
identity store → authorization logic → enforcement boundary. This lab proves host-level IAM enforcement,
which maps directly to secure server administration and production permission design.

#IAM
#Linux
#Authorization
#LeastPrivilege
#chmod
#SecurityEngineering
← Back to IAM Hub
Next: In progress →