The Gate Is Only as Good as Its Bypasses
Every lesson so far assumed one thing: that a request for a picture goes through Gate.check. If any code path can reach a camera without it, the modes, the red eye and the close order are decoration. Security engineers call the property complete mediation: every access is checked, every time. Oriel enforces it in four layers, and the interesting thing is that three of them are about code that does not exist yet.
Layer 1: The Only Channel Carries the Gate
The engine reaches the recorder only through RecorderLink, and every link asks the gate before every want, peek and move. A link built without a gate does not quietly work: it refuses everything with "no eyes gate on this recorder link". So a new command-line tool that builds its own link, as tools sometimes do, gets the same answer a brain would.
Layer 2: A Test That Scans the Code and Scripts
The first layer protects the channel. It cannot stop someone from writing a second channel: calling ffmpeg with an avfoundation input, using a UVC control tool directly, writing desired.json from some other module. So one test, test_no_path_in_the_repository_reaches_a_camera_around_the_gate, does three things:
- It builds a bare link and checks that a want, a peek and a move are all refused, and that nothing was written to the recorder's folder.
- It scans the Python files directly in
backend/and the scripts directly inscripts/(one level each; files in nested folders are not read, a gap worth knowing) for the signatures of device access (adesired.jsonpath, anavfoundationinput,AVCaptureDevice., auvc-utilcall) and fails on any file outside an explicit two-file allow list: the recorder link itself and the satellite agent, which only copies what the engine's gated link already wrote. - It checks that every
RecorderLink(constructed in those top-level backend files carriesgate=, unless that line only lists devices or reads status.
A text scan is crude, and that is fine. It is not trying to understand the code; it is a tripwire. The day someone adds a shortcut to a camera, the suite fails with the file name, and the conversation about whether that shortcut should exist happens before it ships.
Layer 3: Native Probes Ask Before They Open
Some of Oriel's native helpers open devices themselves: the HDMI audio probe, a frame-rate probe. They live outside the engine, so the engine cannot wrap them. Instead they ask. Before opening anything, a probe calls GET /api/gate/device with the device's ID and the kind of media, and it refuses with exit status 7 when the answer is no, when there is no answer, or when it was not even told where the engine is (no --gate flag). The audio probe asks again every 10 seconds and ends its take on a refusal. One subtlety: when it runs as the recorder's helper during a recording, it ends on the engine's own "no", never on the engine's silence during a restart, so a deploy does not cut a recording's sound. Run on its own, an unanswered check refuses like any other. A list-only mode (--list) opens nothing and asks nothing. And a test fails if any probe opens a device without asking first.
Layer 4: Other Systems Ask Too
The same route answers callers outside Oriel. When Haven, the family's home-control app, is about to open a network camera's stream for one frame, it asks Oriel's gate first, so even a caller that skips Oriel's own look is refused at Haven. A camera on another Mac goes through the same gate as a home one (the last track shows how). And an export of a frame to leave the house passes the gate as well as its own checks.
One More Door: Stale Requests at Start
One bypass is not a code path but a timing: a peek or a move left in desired.json by an engine that died mid-wait would be honoured by the next recorder process, after the gate may have closed. The engine clears every one-shot request as it starts. A gate is not only about who may ask; it is also about requests that outlive the permission they were made under.