Constants and Catalogs

Numeric constants — right bits, type values, enum members, limits — are catalogued in exactly one place each. This topic is either that place or a pointer to it.

What lives here #

What lives elsewhere #

Three catalogues are owned by documents that also define their semantics, and are not duplicated here.

The three pages above are signposts. Following one gets you to the table.

Related catalogues #

• Every event type the system emits: the Peios Events Index.
• Every audit event's payload schema: the same book, chapters 3 to 8.

The well-known SID catalogue is PCDS §4.4, in the Peios Core Data Structures specification. It is normative there, and is not duplicated here.

It covers the universal SIDs (S-1-1-0 Everyone, S-1-3-0 CREATOR OWNER, and the rest), the NT authority SIDs under S-1-5, the BUILTIN groups under S-1-5-32, domain SID structure, integrity label SIDs under S-1-16, capability SIDs under S-1-15, service SIDs under S-1-5-80, and the PIP trust labels under S-1-19.

For the conceptual treatment — which principals matter and why — read Well-known principals.

A note on the BUILTIN range #

PCDS lists the BUILTIN groups KACS assigns meaning to. It deliberately does not enumerate S-1-5-32-547 through S-1-5-32-583, which Active Directory defines: KACS gives them no special semantics, and they participate in ACE matching like any other group SID.

An older revision of this reference tabulated them. That table was removed on purpose, not lost — enumerating names the system does not act on implies a behaviour that does not exist.

PIP trust labels #

The S-1-19-T-L ladder encodes two dimensions: T is the PIP type axis, L the trust axis. Dominance requires both to be greater than or equal.

The numeric tiers are in Other constants, and the full SID list is in PCDS §4.4. The mechanism is Process integrity protection.

The per-privilege catalogue — every name, its LUID bit position, and what it does — is in the Peios Kernel TRM §3.4.2, "Catalogue". It is not duplicated here.

The conceptual treatment is Privileges, and the four-category model is Categories.

Five privileges influence an access check #

Only five can contribute bits to a granted mask, and therefore only five can appear in a privilege-use event:

• SeSecurityPrivilege
• SeTakeOwnershipPrivilege
• SeBackupPrivilege
• SeRestorePrivilege
• SeRelabelPrivilege

Any other bit fails the audit encoder closed rather than emitting an unnamed privilege. See the Events Index §3.3.

Two are enforced but not nameable #

SeTakeOwnershipPrivilege and SeRelabelPrivilege are enforced by KACS but absent from the published privilege table, so they cannot be named in a service's RequiredPrivileges. A service needing either declares nothing and takes its source token's defaults, or fails to start if it tries to name one.

That asymmetry is peinit's, not the kernel's — see the peinit TRM §4.5.

The ACE catalogue is PCDS §5.4, in the Peios Core Data Structures specification. It is normative there, and is not duplicated here.

It covers every AceType value from 0x00 to 0x15 — the body layout of each family, the AceFlags bits, and the ACL revision rules that constrain which types may appear.

Twenty of those values have behaviour. Two do not: 0x04 (ACCESS_ALLOWED_COMPOUND_ACE, never implemented anywhere) and 0x15 (SYSTEM_ACCESS_FILTER_ACE, an MS-DTYP type Peios has not implemented). Both are named by the kernel ABI so that a decoder can label the byte, but neither affects an access decision: they are skipped when the descriptor is evaluated and preserved unchanged when it is written back. sd has no name for either and prints them as OTHER(0x04) and OTHER(0x15).

Two names per type #

PCDS names both the ACE structure and the AceType constant that selects it, because a reader may arrive with either — one from a declaration, the other from a hex dump. ACCESS_ALLOWED_ACE is the structure; ACCESS_ALLOWED_ACE_TYPE is the constant whose value is 0x00.

The headers use a third spelling, moving the qualifier to the front: KACS_ACE_TYPE_ACCESS_ALLOWED. The Peios Kernel TRM §3.A maps the two vocabularies.

Inheritance flags #

The four propagation flags and the INHERITED_ACE provenance flag are catalogued with the inheritance algorithm in PCDS §5.6, rather than with the type values.

MIC policy bits #

The mask of a SYSTEM_MANDATORY_LABEL_ACE carries policy bits saying what a non-dominant caller may not do. Those bits are in PCDS §5.4 alongside the ACE type; the mechanism is Mandatory integrity control.

The 32-bit access mask has the same shape for every object type. Bits 0–15 are object-specific, 16–20 are standard rights, 24–25 are special, 28–31 are generic. The standard, special and generic regions are uniform; the object-specific bits carry different meanings for different object types.

This page is the catalogue of right values. What the mask means — how it is evaluated, how generic bits expand — is PCDS §5.3, which is normative. The bit layout of the mask within a descriptor is PCDS §5.1.

File access rights #

The directory names are aliases: identical bit values, different naming convention depending on whether the object is a file or a directory.

File GenericMapping #

FILE_ALL_ACCESS = STANDARD_RIGHTS_REQUIRED | SYNCHRONIZE | 0x1FF = 0x001F01FF.

Process access rights #

Bits 0x0004, 0x0008, 0x0080 and 0x0100 are unused.

Process GenericMapping #

PROCESS_ALL_ACCESS = STANDARD_RIGHTS_REQUIRED | SYNCHRONIZE | 0x1FFF = 0x001F1FFF.

Token access rights #

TOKEN_QUERY_SOURCE is a documented bit position rather than an enforced right: a token fd granting TOKEN_QUERY suffices for everything, and TOKEN_QUERY_SOURCE is not separately checked.

Token GenericMapping #

TOKEN_ALL_ACCESS = STANDARD_RIGHTS_REQUIRED | 0x01FF = 0x000F01FF. Note the absence of SYNCHRONIZE, unlike the file and process aggregates.

Registry-key access rights #

Bits from 0x0040 upward are reserved.

Registry GenericMapping #

Service access rights #

Standard, special and generic rights #

The STANDARD_RIGHTS aggregates #

Three of these are the same value. STANDARD_RIGHTS_READ, _WRITE and _EXECUTE are all aliases of READ_CONTROL, which surprises people reading a mask and expecting them to differ. Only STANDARD_RIGHTS_REQUIRED and STANDARD_RIGHTS_ALL name distinct values.

STANDARD_RIGHTS_REQUIRED is the conventional minimum included in every *_ALL_ACCESS aggregate.

Enumerated values that are not access rights. Access rights are catalogued separately in Access mask bits.

Impersonation levels #

A token's impersonation level. The conceptual model is Impersonation levels.

Older documents spell these KACS_LEVEL_*. That spelling does not exist in any header.

A primary token reports level 0.

Integrity levels #

The RIDs used in S-1-16-* SIDs and in a token's integrity_level field. The model is Mandatory integrity control.

Spaced by 4096, so future levels can be inserted between existing ones.

These are named levels, not a closed enum. The integrity level is the S-1-16 SID's single sub-authority as an unsigned integer, compared numerically. Any such value is valid, and non-standard ones appear in Windows-interop descriptors — medium-plus at 8448, protected at 20480. Code that switches on the five names will mishandle those.

Mandatory policy flags #

A token's mandatory_policy field. Both are immutable after token creation.

Logon types #

A session's logon_type field. The model is Logon types.

Values 1, 6, 7 and 10 upward are reserved.

Elevation types #

A token's elevation_type field.

PIP tiers #

A process's PSB pip_type field.

There are no public constants for these. Nothing in uapi/pkm/ names the tiers, and PIP_TYPE_NONE / _PROTECTED / _ISOLATED — which older documents use — exist nowhere in the tree. Protected survives only as the kernel-private PKM_KACS_PIP_TYPE_PROTECTED.

A program reasoning about tiers compares the numbers. The Peios Kernel TRM §3.7 says the same.

Token audit policy flags #

A token's audit_policy field. These are what force the audit events in the Events Index.

Create dispositions #

For kacs_open.

Older documents spell these KACS_FILE_SUPERSEDE, KACS_FILE_OPEN and so on. That spelling does not exist in any header.

SECURITY_INFORMATION flags #

For kacs_get_sd and kacs_set_sd. Declared as KACS_SECINFO_*; the names below are the MS-DTYP spellings PCDS uses.

SACL_SECURITY_INFORMATION and LABEL_SECURITY_INFORMATION are mutually exclusive in one call.

Process mitigation flags #

The KACS_MIT_* flags on the PSB. The catalogue of what each one gates is Process mitigations.

Size and count limits #