permissions (library)
Roles and permission checks — the "least privilege" part of
Architecture › Rule 4 and the
role model from Rule 5. Source in libs/permissions/. The kernel module that
publishes the live service is permissions (module 0.2).
Types
| Type | Role |
|---|---|
Role | player < moderator < admin. hermes is a separate service role that includes only player and can never manage roles |
PermissionTable | node → minimum role; unknown nodes are denied. PermissionTable.defaults() holds the kernel nodes (see below). Nodes can additionally be granted to hermes by name, except shatterveil.role.manage, which the table refuses |
PermissionService | roleOf(uuid), has(uuid, node), has(sender, node) (console always allowed), setRole(...) |
CachedPermissionService | The standard implementation: a concurrent cache in front of a RoleStore |
RoleStore | Where assignments live; inMemory() for tests and for running without a database, ClickHouse (player_roles) in the permissions module |
Permissions | require(services, node) builds a CommandCondition that looks the service up on every check; check(...), actorName(sender) |
Default permission nodes
| Node | Minimum role | Also granted to hermes |
|---|---|---|
shatterveil.help.use | player | (via player) |
shatterveil.module.view | moderator | ✔ |
shatterveil.admin.read | moderator | ✔ |
shatterveil.module.manage | admin | |
shatterveil.role.manage | admin | never |
How it's wired
The permissions kernel module publishes the PermissionService in the
ServiceRegistry. Commands built with the commands library
get their condition from Permissions.require automatically, using the
permission declared in their CommandDoc. Because the condition resolves the
service on every check, a role change takes effect immediately and a missing
service (module failed to enable) denies everyone but the console.