Fence vault fills at the Chromium process owner

[hiroTamada]

Deferred — not a dependency of kernel/kernel#3957

This companion remains draft. Do not merge or deploy it as part of the current vault-fill work.

The current scope uses control-plane Redis locking and quarantine with ordinary CDP routing. Redis key loss can admit an overlapping writer while an earlier Chrome command is still executing; that limitation is explicitly accepted for this scope. The API change will not require this image or negotiate this owner protocol.

State of this branch

Published head: f43a685128f4157501d803da73293ab247ac7db2.

• The initial owner implementation is retained for future work.
• Existing image E2E CI fails because unconditional process inspection can prevent ordinary Chromium startup on permission denial.
• The published owner also buffers between-command Chrome events until the next command is sent. Both review findings remain unresolved on this published head.
• Follow-up compatibility/event-reader changes and an actual-owner regression were explored locally but are not part of this head. They are deferred, not approved or fully validated.
• Actual-image lifecycle, reset/restart, snapshot/fork, and full HTTP adversarial validation remain incomplete. Prior protocol/unit tests do not establish those guarantees.

Any future revival needs a separate scope decision, both review fixes, compatibility validation on supported runtimes/user modes, and complete lifecycle/adversarial testing before release. No merge, deployment, or fill-gate change has been performed.

[hiroTamada]

Two issues need correction before this companion is merge-ready:

1. P1: normal Chromium startup regresses under the existing container permissions. The new launcher calls StopPrevious unconditionally. The server E2E job repeatedly reports browser owner stopped: inspect process: readlink /proc/27/exe: permission denied (also PID 26), and Chromium never becomes ready. TestOTLPExport and TestOTLPExportForkIdentityRefresh fail at startup. This affects normal browsers independently of the API fill gate. Fix the process inspection/ownership design without simply skipping a possible surviving browser or making tests privileged; rerun the existing container E2E suite and verify supported runtime/user modes. CI evidence: https://github.com/kernel/kernel-images/actions/runs/34767926509/job/103752354129 .

2. P1: Chrome events stop flowing between client commands. Fence.ServeHTTP only reads upstream inside the response loop after forwarding a client command. Navigation/frame events arriving while the API is performing a guard or resolving a value remain buffered until the next command is already sent. Page.check can therefore use stale frame revisions when authorizing that next transfer/write. Keep upstream event delivery active independently of command admission while retaining strict response accounting and exclusive ownership. Add an actual-owner regression where a bound ancestor navigates or changes its URL during a paused guard/resolver and verify the subsequent write is rejected. Protocol-only adapters do not exercise this behavior.

The full new-owner HTTP and adversarial lifecycle validation also remains pending. No merge approval at this revision.

[hiroTamada]

Follow-up to this review: this companion is deferred, not merge-ready. Its branch remains available at f43a685128f4157501d803da73293ab247ac7db2.

kernel/kernel#3957 now uses ordinary CDP with explicitly limited control-plane Redis locking and does not depend on this image change. The published image head still has both reported issues; they are not claimed fixed or validated. The PR body records that status and the incomplete lifecycle validation. No merge or deployment was performed.