Resource Authority

Librux resource authority is host-local. A host owns its CPU cores, NICs, CAN interfaces, serial nodes, device nodes, and frontend listener ports.

Managed launch makes those resources visible before a subsystem depends on them.

flowchart LR PKG["Managed package instance"] LAUNCH["launcher"] RES["librux-resourced"] LEASE["Resource lease"] PROC["subsystem process"] BROKER["SDK resource broker"] HANDLE["accepted handle<br/>socket, device FD, or launch grant"] PKG --> LAUNCH LAUNCH -->|"claim resources"| RES RES --> LEASE LAUNCH -->|"start with lease env"| PROC PROC --> BROKER BROKER -->|"request handle"| RES RES --> HANDLE HANDLE --> PROC

Authority Model

Communication APIs alone cannot answer whether a subsystem is allowed to use a host outlet. Librux separates that decision.

Communication surfaces describe how subsystems exchange data.
Resource authority decides whether a managed subsystem may use a host resource.

The resource service accepts or rejects claims against live allocations and host inventory. When a resource supports brokered access, the process receives a specific accepted handle instead of broad host permissions.

Resource Classes

Librux treats resources according to their Linux semantics.

Resource	Runtime behavior
CPU	process affinity, scheduler policy, and cgroup placement when the privileged service path is available
NIC	shared by default, exclusive for dedicated links, optionally brokered for UDP/TCP sockets
Link-layer raw packet	exclusive raw Ethernet claim for EtherCAT-class fieldbus gateways
CAN	SocketCAN claim, with brokered `AF_CAN` FD delivery when enabled
Serial and device nodes	accepted device FD delivery instead of broad device-group access
Frontend loopback	instance-scoped `127.0.0.1` listener grant for app UI backends

Link-layer raw packet claims are intentionally different from brokered UDP/TCP network sockets. EtherCAT-class gateway packets stay on the gateway process data path. librux-resourced admits the claim and grants the bounded launch-time capability, but it does not relay every fieldbus packet.

Application Resource Boundary

Packages with subsystem.role: app have a narrower policy than general subsystem packages.

Application packages must use resources.sandbox.network: brokered, and avoid direct hardware-facing network, link-layer, CAN, serial, or device claims.

Package browser UI is packaged as static frontend assets and served by librux-control. Instance-specific GUI communication goes through frontend.context and managed frontend listener grants. Browser code should not discover or hardcode backend ports.

This keeps application subsystems business-facing and platform-facing, while gateway and component packages own lower-level resource interaction.

Boundary With Host Policy

Managed launch is the Librux-controlled path. If a user bypasses the launcher and executes arbitrary programs directly, host policy still matters.

Product deployments should combine Librux with appliance-level policy.

run librux-control.service as the dedicated non-root librux user
run resource and time-sync companions as narrow privileged systemd services
restrict protected device nodes with udev rules
avoid adding ordinary users to broad device access groups
require product subsystems to run as managed packages
restrict root or unmanaged shell access according to the product threat model

This keeps Librux in the Linux framework layer while allowing an appliance-style deployment to behave like a controlled robotics runtime.

Relation To Communication Surfaces

Communication surfaces describe runtime data semantics. Resource authority describes host admission.

A subsystem may use Event, Control, Procedure, Operation, or WebSocket while its IP socket, CAN socket, serial FD, device node, or frontend listener is delivered through the managed resource broker. The two layers meet at the runtime boundary, but they answer different questions.