User & File System Privileges — Explain users, groups, permissions, and file system privileges (conceptual)

The concept of user privileges and file system permissions arose from a fundamental problem in computing: when multiple users share a single machine, how do you prevent one user from reading, modifying, or destroying another user's data? Early mainframe systems in the 1960s were among the first to confront this challenge, as universities and government agencies needed to allow dozens—sometimes hundreds—of concurrent users to operate on a single computing resource without interference. The solution was to embed access control directly into the operating system, creating a model that persists, in refined form, in every modern OS today.

The enduring question that these developments address is deceptively simple: who should be able to do what, and to which resources? Every security breach involving unauthorized file access, privilege escalation, or data exfiltration is ultimately a failure in the mechanisms designed to answer this question. Understanding the conceptual architecture of user accounts, group memberships, and permission models is therefore foundational to systems security—whether you are hardening a Linux server, administering a Windows domain, or designing a cloud-native application with role-based access.

Before examining any specific operating system's implementation, it is essential to establish the conceptual primitives that underlie all privilege systems. These primitives—subjects, objects, and operations—form the basis of every access control decision. A subject is any active entity requesting access (a user, a process, or a service). An object is any passive resource being accessed (a file, a directory, a device, or a network socket). An operation is the action requested (read, write, execute, delete). The privilege system's job is to consult a stored policy and determine whether a given subject may perform a given operation on a given object.

The following diagram illustrates how a Unix-style permission string maps to its binary and octal representations, and how the kernel resolves an access request by checking the subject's UID and GID against the file's metadata (the inode). When a process issues a system call like open(), the kernel extracts the process's effective UID and GID, compares them to the file's owner UID and group GID stored in the inode, and then evaluates the corresponding permission bits.

The key insight from the diagram is that the kernel performs its checks in a strict order: it first tests whether the effective UID is 0 (root), in which case nearly all checks are bypassed. If the process is not running as root, the kernel checks whether the effective UID matches the file's owner UID. If it does, only the owner permission bits are evaluated—the group and other bits are ignored entirely. If the UID does not match but the process's effective GID (or supplementary groups) matches the file's GID, then only the group permission bits are checked. Finally, if neither UID nor GID matches, the others bits determine access. This cascading logic means that it is possible for a file's owner to have fewer permissions than the group, a subtlety that occasionally surprises even experienced administrators.

Each of the three permission scopes (owner, group, others) is encoded as a 3-bit binary number, yielding an octal digit between 0 and 7. Together, the three digits form the familiar octal permission mode. An optional leading digit encodes special permission bits—setuid, setgid, and the sticky bit—which modify execution and deletion behavior in security-critical ways.

Operating systems implement access control through distinct models, each with different trust assumptions and granularity. The choice of model has profound implications for both usability and security. Unix-like systems traditionally rely on Discretionary Access Control (DAC), where the resource owner decides who gets access. Windows NTFS extends this with Access Control Lists (ACLs) that allow arbitrary per-user and per-group entries. Higher-security environments employ Mandatory Access Control (MAC) or Role-Based Access Control (RBAC) to enforce organization-wide policies that individual users cannot override.

In Windows NTFS, every file and directory carries a security descriptor containing the owner's Security Identifier (SID), the group SID, a Discretionary Access Control List (DACL), and a System Access Control List (SACL). The DACL is an ordered list of Access Control Entries (ACEs), each specifying a trustee (user or group SID), an access mask (the specific permissions), and a type (Allow or Deny). The SACL controls auditing—which access attempts generate log entries. Critically, Deny ACEs are evaluated before Allow ACEs, so an explicit denial always wins. This stands in contrast to the Unix model, where the first matching scope (owner, group, other) determines the result and there is no native concept of an explicit Deny entry without extended ACLs.

Consider the following scenario: a web server running as the user www-data (UID 33, primary group www-data GID 33) must serve static HTML files from /var/www/html/. Developers in the webdev group (GID 1010) need to read and write files in this directory. No other users should have any access. We need to determine the correct ownership and permissions.

No single access control model is universally optimal. The traditional Unix DAC model trades granularity for simplicity, while NTFS ACLs and MAC frameworks offer precision at the cost of administrative complexity. Understanding these trade-offs is essential when designing or auditing a system's security posture.

The concepts covered in this lesson—users, groups, and permission bits—represent the practical surface of a deeper theoretical framework in computer security. The formal study of access control centers on two classical models: the Bell-LaPadula model (1973), which enforces confidentiality through "no read up, no write down" rules, and the Biba model (1977), which enforces integrity through the dual "no read down, no write up" principle. These models formalize what practical permission systems approximate through labels, clearance levels, and policy enforcement.

As you advance in systems security, you will encounter scenarios where traditional user/group/permission models are insufficient. Cloud-native environments introduce identity federation (OAuth, SAML), short-lived credentials, and policy-as-code frameworks like Open Policy Agent (OPA). Container orchestration platforms like Kubernetes implement their own RBAC layer atop the kernel's access controls. Understanding the foundational model presented here is essential because every advanced mechanism is ultimately an extension, refinement, or replacement of the subject–object–operation paradigm.