Chapter 20Authorization

This chapter gives an abstract, implementation-neutral description of authorization in GQL, focusing on how principals, roles, and privileges constrain access to catalog and data objects. In the broader security context, we use the term security primarily in the sense of authorization (access control): the rules that determine which principals may reference which GQL-objects, and which operations are permitted on them. Rather than fixing a specific access-control mechanism, we model privilege grants, obligation sets, and object availability in a way that can be instantiated by concrete implementations while preserving the previously defined pure semantics.

20.1 Roles and Privileges

Privileges. Let $\mathit{\mathbb{P}ℝ𝕀𝕍}$ be the (implementation-defined) set of privilege kinds/levels (e.g., read, write, execute, administer, or finer-grained variants thereof). Privileges are modeled as a finite poset $⟨\mathit{\mathbb{P}ℝ𝕀𝕍},\le ⟩$, where $\varpi \le {\varpi }^{\prime }$ is read as “${\varpi }^{\prime }$ dominates (implies) $\varpi$”, i.e., possessing ${\varpi }^{\prime }$ suffices wherever $\varpi$ is required. We write $\bigsqcup <!--\; FUNCTION\; APPLICATION\; -->P$ for the least upper bound (join) of a finite set $P\subseteq \mathit{\mathbb{P}ℝ𝕀𝕍}$ (assumed to exist in this abstract model). The concrete elements of $\mathit{\mathbb{P}ℝ𝕀𝕍}$ and their ordering are implementation-defined; here we reason over abstract elements $\varpi \in \mathit{\mathbb{P}ℝ𝕀𝕍}$ without fixing names or generators.

Authorization identifiers, roles, and authorization targets. Let ($\mathit{𝔸𝕀𝔻}$) be the set of authorization identifiers. Each authorization identifier ($a\in \mathit{𝔸𝕀𝔻}$) identifies a principal together with a set of privileges under which GQL requests associated with (a) are executed. A single principal may be identified by more than one authorization identifier, allowing the same principal to operate under different privilege sets, for example under a restricted context for ordinary queries and a more privileged context for management operations.

Let ($\mathit{ℝ𝕆𝕃𝔼}$) be an implementation-defined set of roles used to structure privilege assignments. A role represents a reusable grouping of related privileges and may be associated with one or more authorization identifiers. Typical role categories may provide read-only access, permission to modify graph data, permission to execute named procedures, permission to manage schema objects, or permission to administer privilege assignments. The available roles, their names, and the mechanism by which they are associated with authorization identifiers are implementation-defined.

Let ($\mathit{𝕆𝔹𝕁}$) be the set of authorization targets, that is, entities to which privileges may apply. In the core model, authorization targets are complete GQL-objects, such as graphs, graph types, binding tables, and named procedures. Thus, a privilege may permit a particular class of operations, such as reading, modifying, executing, defining, or administering, on an individual authorization target or on a class of such targets. The set of privileges identified by an authorization identifier is implementation-defined. An implementation may additionally define privileges on graph elements, labels, or properties, but that is an extension whose effect on query evaluation must also be defined by that implementation; the core semantics below does not silently turn a stored graph into a filtered subgraph.

Grants. An authorization state $\mathcal{Z}$ is a finite set of facts:

where $g\in \mathit{𝔸𝕀𝔻}$ is a grantor, $x\in \mathit{𝔸𝕀𝔻}\cup \mathit{ℝ𝕆𝕃𝔼}$, $\varpi \in \mathit{\mathbb{P}ℝ𝕀𝕍}$, $o\in \mathit{𝕆𝔹𝕁}$. (Grant-option policy and catalog specifics are implementation-defined.) Effective privilege for authorization identifier $u$ on object $o$ is

taking joins in the poset $⟨\mathit{\mathbb{P}ℝ𝕀𝕍},\le ⟩$.

20.2 Privilege Obligations and Enforcement

Obligation judgments. Let $\Theta$ be the binding-name-to-type environment used while typing a statement, and let $𝔖$ be the applicable static schema/type context. We extend typing with a privilege obligation set:

where ${\mathrm{\Pi }}_S\subseteq \mathit{\mathbb{P}ℝ𝕀𝕍}\times \mathit{𝕆𝔹𝕁}$ is the least set of privilege–object pairs required by the syntactic constituents of $S$. The set is computed compositionally: each primitive language construct contributes the obligations specified by its typing rule, while the obligations of a compound construct are obtained by taking the union of the obligations computed for its immediate subconstructs. For example, sequential composition satisfies

$$$$.

Thus, no privilege obligation belongs to ${\mathrm{\Pi }}_S$ unless it is introduced by a constituent of $S$ or by a rule for composing such constituents; repeated occurrences of the same obligation collapse because ${\mathrm{\Pi }}_S$ is a set.

The mapping from language constructs to required privilege kinds is implementation-defined; we therefore use abstract placeholders: let ${\varpi }_{\mathit{match}},{\varpi }_{\mathit{insert}}\in \mathit{\mathbb{P}ℝ𝕀𝕍}$ be representative required privilege kinds and let $o_{\phi },o_G\in \mathit{𝕆𝔹𝕁}$ be the corresponding authorization targets.

$$$$.

Authorization check (dynamic). At execution under session authorization identifier $u$, the engine verifies that, for every required privilege–object pair $(\varpi ,o)\in {\mathrm{\Pi }}_S$, the effective privileges of $u$ on $o$ include or dominate the required privilege $\varpi$:

Equivalently, authorization succeeds only if there is no $(\varpi ,o)\in {\mathrm{\Pi }}_S$ such that $\mathrm{eff}(u,o)\ge ̸\varpi$. If this condition is not satisfied, the statement is rejected before its evaluation begins, and an appropriate authorization diagnostic is raised.

The objects in ${\mathrm{\Pi }}_S$ are determined from the syntactic form and catalog context so that authorization completes before the statement’s General Rules are evaluated. Refining this required check later from objects actually accessed during execution is outside the core model.

Minimality/monotonicity. ${\mathrm{\Pi }}_S$ is minimal up to poset equivalence. We write $S\preccurlyeq S^{\prime }$ to mean that $S^{\prime }$ is a contextual extension of $S$, i.e., there exists a (single-hole) statement context $C[\cdot ]$ such that $S^{\prime }=C[S]$ (so $S$ occurs as a syntactic substatement of $S^{\prime }$). Then obligations are monotone under such extensions: if $S\preccurlyeq S^{\prime }$, then ${\mathrm{\Pi }}_S\subseteq {\mathrm{\Pi }}_{S^{\prime }}$.

20.3 Authorized Object Access

Object availability. An execution context provides access only to the complete GQL-objects available to it. We represent this implementation-defined availability by

Availability controls object reference and name resolution; permission to perform an operation is separately determined by the effective privileges of the session authorization identifier. In particular, availability of a graph does not denote availability of an induced subgraph.

Query semantics under authorization. Let $\mathit{⟦S}{⟧}_{\mathcal{K},G}$ denote the pure semantics of a query statement $S$. Its authorization-identifier-indexed semantics is

Thus an authorized query reads the ordinary, complete graph state. If the execution would perform an operation not permitted by the privileges identified by the session authorization identifier, the request instead raises syntax error or access rule violation (42000). Any finer-grained row-, element-, label-, or property-filtering semantics is an implementation-defined extension and is not inferred from this core model.

20.4 Write Checks

Write-related obligations. The obligation set ${\mathrm{\Pi }}_S$ for a statement $S$ may contain privileges corresponding to read-only operations, write operations (data-modifying or catalog-modifying), or both. GQL characterizes privileges as permissions to cause certain kinds of operations to be performed and specifies that if the execution of a GQL-request would perform an operation not permitted by the privileges of the session authorization identifier, then the exception 42000 is raised. We model this by requiring that, for every operational step of $S$ that attempts to modify a catalog or data object $o$, there is some $(\varpi ,o)\in {\mathrm{\Pi }}_S$ such that $\mathrm{eff}(u,o)\ge \varpi$; otherwise, execution raises 42000 before that modification takes effect.

Interaction with transaction access mode. GQL distinguishes the transaction access modes $\mathrm{READ}\mathrm{ONLY}$ and $\mathrm{READ}\mathrm{WRITE}$, abbreviated as $\mathrm{RO}$ and $\mathrm{RW}$, respectively, and mandates that:

• Executing a linear catalog-modifying statement when the current transaction access mode is $\mathrm{RO}$ raises invalid transaction state—read-only GQL-transaction (25G03).
• Executing a linear data-modifying statement when the current transaction access mode is $\mathrm{RO}$ likewise raises 25G03.
• Executing such statements when the current transaction access mode is $\mathrm{RW}$ is not rejected by the transaction access-mode rule (i.e., 25G03 is not raised on that basis); any rejection must arise from other rules, such as privilege checks.

Let

be the current transaction access mode. For a statement $S$ whose syntactic statement kind is data-modifying or catalog-modifying, dynamic execution under session authorization identifier $u$ proceeds as follows: first perform the privilege check

raising 42000 on failure before the statement’s General Rules are applied. If authorization succeeds, those General Rules then apply the transaction-mode check

The modifying operations of $S$ are permitted to proceed only if both checks succeed; the authorization step precedes the statement-level read-only check.

Atomicity and failure behavior. Transaction management in GQL requires that a transaction is atomic with respect to recovery: a request that raises 25G03 or 42000 has no effect on the GQL-catalog or on GQL-data. If the condition propagates to a failed outcome of the executing procedure, the implementation attempts to roll back the current transaction. Thus:

• No partial writes performed by $S$ are observable in the committed state.
• No later component of the failed request is executed. If rollback succeeds, the transaction is terminated; the effect of a failed rollback attempt is governed by the transaction rules rather than by the authorization condition itself.

An authorization failure therefore supplies the standard access-rule condition; it is not itself reclassified as a transaction-rollback condition. If a transaction-rollback condition is also raised, the diagnostic precedence rules select that condition as primary.