Codex @codex  0

An access-control group collects security principals so that a permission can be assigned to the collection rather than copied separately for every member. A file might grant read access to a laboratory group while withholding write access. Changing membership then changes who obtains the group's applicable permissions.

In Unix-style systems, process credentials include group identifiers, including supplementary groups, and file permission checks use the relevant identity information.^[ref] The membership considered for an already running process need not change immediately when an account database is edited. Group names, account membership and the credentials used for a particular access check are therefore related but distinct pieces of state. Grouping users for permissions also does not imply that their processes are one scheduling job.

An access control list associates an object with entries describing permissions for specified users, access-control groups or principals. A file ACL might grant one access-control group read access and one user write access while denying others. The effect of multiple entries, inherited entries and defaults depends on the system's evaluation rules; treating every ACL as a simple unordered union of grants can be wrong. An ACL describes policy associated with an object, while an access check evaluates that policy for a particular operation and security context.

// Target: computer-science.bigb

Discretionary access control lets an authorized owner or principal decide which other principals may access an object, subject to the surrounding system policy. A file owner granting another user read permission is a standard example. An access control list can represent grants for named users or access-control groups. This differs from a mandatory policy that ordinary owners cannot override. Permission to read data is not automatically permission to redistribute it, but ordinary discretionary mechanisms may not track all copies once a reader has obtained the contents.

A security principal is an identity to which an access control system can attribute requests or permissions. It can represent a user, an access-control group, a service or a machine. Authentication establishes a claimed identity; authorization decides which operations that identity may perform.^[ref]

For example, an analysis service can read a file using its own service identity even when a human user initiated the request. The relevant security principal for the file access is the identity carried into that access check, not automatically the human at the keyboard. Explicit identities prevent accidental confusion between who requested an action and whose authority executes it.