Wire Formats Reference
Single-page view · as markdown
Wire formats reference
Peios / Using Peios / Wire Formats Reference
Byte-level layouts are specified normatively in the PCSA books and in the kernel manual's ABI appendices. This page is the map.
Security descriptors and their parts #
| Structure | Where |
|---|---|
| Security descriptor header, self-relative | PCDS §5.1 |
| ACL header and ACE array | PCDS §5.2 |
| ACE header and per-type body layouts | PCDS §5.4 |
| Access mask layout | PCDS §5.3 |
Claim entry — CLAIM_SECURITY_ATTRIBUTE_RELATIVE_V1 | PCDS §5.9 |
| Conditional-ACE bytecode, with the full opcode table | PCDS §5.11 |
| Resource attribute ACEs | PCDS §5.10 |
See also Security descriptors.
Identifiers #
| Structure | Where |
|---|---|
| SID binary format | PCDS §4.1 |
| SID string format | PCDS §4.2 |
| GUID | PCDS §2 |
| LUID | PCDS §3 |
Kernel interfaces #
| Structure | Where |
|---|---|
| Token and session wire specs | Peios Kernel TRM §3.A — see Token and session specs |
| CAAP wire format | See CAAP format |
| Registry ABI, including watch record layout | Peios Kernel TRM §5.A |
| Token query class payloads | Peios Kernel TRM §3.A |
Event stream #
| Structure | Where |
|---|---|
| KMES event header, field by field | PSPK §2 |
| Event envelope, in summary | Events Index §1.2 |
| Per-event payload schemas | Events Index, chapters 3 to 8 |
Packages and repositories #
The package container, manifest, signature and repository index formats are PSPU §5.
Security descriptors (wire format)
Peios / Using Peios / Wire Formats Reference
The byte-level layout of a security descriptor and everything inside it is specified in PCDS, the Peios Core Data Structures specification. It is normative there and is not duplicated here.
| Structure | Section |
|---|---|
Descriptor header, self-relative form — Revision, Sbz1, Control, and the four offsets | PCDS §5.1 |
| Control flags | PCDS §5.1 |
ACL header — AclRevision, AclSize, AceCount | PCDS §5.2 |
ACE header — AceType, AceFlags, AceSize | PCDS §5.4 |
| Per-type ACE body layouts | PCDS §5.4 |
| Access mask bit layout | PCDS §5.3 |
| SID binary format | PCDS §4.1 |
| Claim entry format | PCDS §5.9 |
| Conditional-ACE bytecode | PCDS §5.11 |
Peios uses the MS-DTYP §2.4.6 self-relative format without translation, so a descriptor written by a Windows domain controller and replicated through Samba is evaluated as-is. Where KACS's evaluator departs from MS-DTYP — a separate question from the format — the Peios Kernel TRM §3.B has the list.
The right values carried in an access mask are catalogued in Access mask bits.
CAAP format
Peios / Using Peios / Wire Formats Reference
The central access policy wire format — the structure kacs_set_caap accepts — is specified in the Peios Kernel TRM §3.A, the KACS ABI reference.
The conceptual model, and what the structures mean, is Policies and rules.
Shape, in summary #
Fields are length-prefixed: each part begins with a 32-bit byte count followed by that many bytes, and an absent field has length zero. That convention runs through the policy blob, its rules, and each rule's applies-to expression and SACL.
The limits that bound it — 256 KB per wire spec, 256 rules per policy, 64 KB per applies-to expression — are in Other constants.
The applies-to expression and the rule SACLs use the same conditional-ACE bytecode as a conditional ACE, specified in PCDS §5.11.
Token and session specs
Peios / Using Peios / Wire Formats Reference
The binary specs that kacs_create_token and kacs_create_session accept, and the payload format of every token query class, are laid out in the Peios Kernel TRM §3.A, the KACS ABI reference. All 46 header offsets and all 24 query classes are there.
The conceptual field list — what a token holds and what each field does — is Token types.
Shape, in summary #
Both specs are length-prefixed throughout: a field is a 32-bit byte count followed by that many bytes, and an absent field has a count of zero. Arrays are a 32-bit element count followed by that many records.
Size limits are 64 KB for a token spec and 4096 bytes for a session spec; both are in Other constants.
The enumerated values a spec carries — impersonation level, elevation type, logon type, mandatory policy, audit policy — are catalogued in Other constants too, under the names the headers declare.
For building a session spec from the command line rather than by hand, logonse types the surface for you; the underlying format is unchanged.