feat(sandbox): support peer-address accept() for server workloads on pre-5.19 kernels (legacy read-only mode)

[russellb]

User Story

As an operator running OpenShell on OpenShift / RHEL 9.x nodes,
I want server-shaped workloads to accept local connections inside the sandbox,
so that agent harnesses that run a local HTTP control server work on my existing fleet without waiting for a kernel bump.

Problem Statement

On kernels before Linux 5.19 the sandbox runs in legacy read-only mode, where the broker refuses the mediated operations that write results back into workload memory. For accept/accept4 this means the call succeeds with a null peer-address argument and fails closed with EOPNOTSUPP with a non-null one.

This is documented and deliberate (support matrix). Without SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV a non-fatal signal can cancel the notification and restart the syscall between SECCOMP_IOCTL_NOTIF_ID_VALID and the broker's cross-process write, so the workload may free or reuse the buffer before the write lands. There is no atomic validate-and-write ioctl for memory the way SECCOMP_IOCTL_NOTIF_ADDFD provides one for descriptors.

The gap is that OpenShell offers no alternative path for these workloads. #3417 made the sandbox start on 5.14; this is the next layer of consequence, which that issue's acceptance criteria did not cover.

Impact / Why This Matters

Today, operators on RHCOS/RHEL 9.x must either run the workload outside the sandbox or move to a node kernel with WAIT_KILLABLE_RECV. Neither is available in-cluster: the kernel is fixed for the RHEL 9 lifecycle, and running outside the sandbox defeats the purpose.

Observed on a 5.14.0-570.103.1.el9_6 node: OpenCode fails its readiness timeout because its local server cannot accept connections. A direct in-sandbox test confirmed accept() with a peer-address argument returns EOPNOTSUPP. No network-policy denial is reported, because this is a mediation refusal rather than a policy decision.

The affected set is wider than one tool. The trigger is the accept wrapper of whatever runtime the workload uses, not the workload's own code. CPython's socket.accept() always passes a peer-address buffer; so does uSockets, which is what Bun-based harnesses go through. Notably, these workloads do not need the value — a loopback-only control server never reads the peer address.

RHCOS is the default OpenShift substrate, so this recurs for every server-shaped workload anyone tries to sandbox there.

Proposed Design

In legacy read-only mode, make accept/accept4 with a non-null peer-address argument succeed, with the address supplied by the workload process itself rather than written across process boundaries by the broker.

Externally observable behavior:

• On a pre-5.19 node, a workload calling accept(fd, &addr, &len) receives a working connected descriptor and a populated sockaddr, instead of EOPNOTSUPP.
• The returned address reports the correct family and loopback IP. The peer port may be reported as 0 if the real value is not recoverable; this should be documented rather than silently implied to be accurate.
• addrlen follows accept(2) semantics, including reporting the true size when the caller's buffer is too small.
• Behavior on 5.19+ nodes is unchanged.
• The isolation boundary is unchanged. The broker still mediates the accept, still enforces the existing loopback-only peer check, and still registers the accepted descriptor so subsequent operations on that connection remain mediated.
• Coverage limits are stated in the support matrix, including which workload classes are not covered.

The security property this must preserve: the write happens inside the workload's own address space with the workload's own privileges, so it cannot do anything the workload could not already do. The TOCTOU that forces today's fail-closed is specific to the broker's cross-process write; performing the write in-process removes it by construction rather than by narrowing the window.

One approach that satisfies this is a small preload library shipped in the sandbox image and enabled only when seccomp_listener_mode == legacy_read_only, which issues the null-address accept the broker already permits and fills in the caller's buffer locally. Its known limit is that it only covers callers reaching accept4 through a dynamic libc symbol — a statically linked Go binary issuing the syscall directly would bypass it. Implementers should weigh this against alternatives.

Explicitly out of scope: answering the notification with SECCOMP_USER_NOTIF_FLAG_CONTINUE. That would let the kernel perform the write safely, but the accepted descriptor would never pass through the broker's registry, losing the loopback check and all subsequent mediation of that connection.

Alternatives Considered

• Require a 5.19+ node kernel. Leaves current OpenShift and RHEL 9 users blocked for the RHEL 9 lifecycle. This is the status quo.
• Have the broker write anyway, relying on NOTIF_ID_VALID alone. Reintroduces the race that legacy read-only mode exists to avoid. Not acceptable.
• SECCOMP_USER_NOTIF_FLAG_CONTINUE for accept. Safe write, but surrenders mediation of the accepted socket. See above.
• Document the limitation only, and let users patch their own images. Already effectively the situation; it pushes a subtle, security-adjacent shim onto every affected user.
• Recover the true peer port for fidelity. Would need a broker side channel; disproportionate, since affected workloads do not read the port.

Acceptance Criteria

• On a pre-5.19 node, a Python workload calling socket.accept() inside the sandbox receives a connected socket and a peer address rather than EOPNOTSUPP.
• On the same node, a Bun- or uSockets-based local HTTP server reaches readiness inside the sandbox.
• The accepted connection remains fully mediated: it is present in the socket registry, and the existing non-loopback peer rejection still applies.
• addrlen truncation semantics match accept(2).
• Behavior and qualification output on 5.19+ nodes are unchanged.
• The support matrix and the OpenShift page state the new behavior, the fidelity caveat on the reported peer port, and which workload classes remain uncovered.
• Coverage limits are verified by test, not only asserted.

Related

• Capability-free sandbox fails to start on kernels < 5.19 (RHEL 9.x / 5.14): seccomp WAIT_KILLABLE_RECV EINVAL #3417 — same root cause (RHEL 9.x / 5.14 lacks WAIT_KILLABLE_RECV). That issue made the sandbox start in legacy read-only mode; this one addresses the server-workload consequence left behind.
• Not related to WSL2 (kernel 6.6.87, Docker Engine): sandbox create fails with "seccomp notification probe: notification launcher disappeared" #3842, which is a distinct qualification-probe failure on a WSL2 6.6 kernel.

Note on observability

While diagnosing this, the legacy-mode refusal was found to emit no log or OCSF event — the workload sees EOPNOTSUPP and the operator sees nothing, which is why the failure initially looked like a policy denial. That is arguably a separate defect worth its own issue, independent of whether this feature is accepted.

[russellb]

🏗️ build-plan

Implementation Plan

Issue type: fix
Complexity: High
Confidence: High — both halves of the fix are implemented, the delivery location is now settled against the Landlock baseline and re-validated on the real OpenShift mount, and no blocking unknowns remain. What is left is e2e validation and docs.

Summary

On kernels < 5.19 there is no SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV, so the broker runs in ListenerMode::LegacyReadOnly and write_socket_addr fail-closes. Every path where the broker must write a sockaddr into the workload's address space therefore fails: accept(fd, &addr, &len) and getpeername(2).

Two different runtimes fail on two different syscalls, so the fix has two parts:

1. Broker-side (getpeername). For SocketState::AcceptedLocal the fd is the genuine accepted socket, so the kernel's own answer is byte-for-byte what the broker has stored. Respond respond_continue and let the kernel write it. No cross-process write, so no WAIT_KILLABLE_RECV dependency.
2. Workload-side (accept). A small freestanding LD_PRELOAD interposition library, injected only in LegacyReadOnly mode, calls the kernel with addr = NULL, len = NULL (already permitted and fully mediated) and then fills the caller's buffer in-process. The workload writes its own memory, so the cross-process TOCTOU that WAIT_KILLABLE_RECV exists to close does not apply.

Step 1 results — approach validated empirically

Built the shim with zig cc -target <arch>-linux-musl -nostdlib -shared -fPIC (zig 0.14.1 is already a pinned project dependency, so no new CI toolchain). Verified on both x86_64 and aarch64:

Invariant	Result	Consequence
DT_NEEDED	none	One artifact per arch loads under both glibc and musl
TEXTREL	none	No SELinux execmod required — the permission most likely denied to container_t
Undefined symbols	exactly __errno_location	Exported by both libcs
Exported FUNC	exactly accept, accept4	No accidental memcpy/memset interposition

Runtime-verified by execution, not inspection: the same .so interposes correctly under Debian/glibc and Alpine/musl.

Bun / opencode — fixed by the shim. The reporting workload is opencode, entirely TypeScript on Bun (no Go anywhere in the tree), serving over node:http createServer(). Under strace, Bun's accept path is:

accept4(7, {sa_family=AF_INET, sin_port=htons(51972), ...}, [128 => 16], SOCK_CLOEXEC|SOCK_NONBLOCK) = 9

A non-null peer-address buffer — so it hits the legacy-mode refusal. This is the root cause of the field report. nm -D on bun shows accept@GLIBC_2.17, accept4@GLIBC_2.17, getsockname@GLIBC_2.17, so Bun routes through libc and is reachable by LD_PRELOAD. With the shim loaded the trace becomes accept4(7, NULL, NULL, ...) followed by a peer-address lookup, and a full HTTP request completes.

Node / libuv — fixed by the broker, not the shim. Node imports accept, accept4, getpeername and getsockname from glibc, so it is reachable by LD_PRELOAD — but it does not need to be. libuv always passes NULL, NULL to accept4, so Node's accept already works in legacy mode today. Node resolves the peer lazily, via a separate getpeername, and only when the application touches req.socket.remoteAddress:

accept4(18, NULL, NULL, SOCK_CLOEXEC|SOCK_NONBLOCK) = 20
getpeername(20, {sin_port=htons(60274), sin_addr="127.0.0.1"}, [128 => 16]) = 0

A probe whose handler ignores remoteAddress emits no getpeername at all and is unaffected; a probe that reads it — as request logging, rate limiting, and x-forwarded-for handling all do — is what exposes the failure. Shimming getpeername in the preload would be actively harmful, because the same symbol is called on outbound Connected sockets where the broker must substitute the original destination; a blanket in-process answer would turn a clean error into a confidently wrong address. The broker is the only layer that knows the socket's state, so the fix belongs there.

Port fidelity. With the broker answering getpeername, the shim calls getpeername rather than getsockname on the injected fd, so it reports the true peer IP and port. This retires the port-0 degradation carried in Revision 2 — which mattered: with an unzeroed getsockname the reported peer port equals the server's own listening port (measured: 41479 reported as peer while the listener was 41479 and the true client port was elsewhere), a plausible-looking wrong answer.

Step 2 results — broker getpeername fix landed

Step 2 is implemented and committed. get_peer_name now responds respond_continue for Local and AcceptedLocal, and keeps substituting original_peer for Connected. Verified test-first: the new AcceptedLocal/Local test failed with errno 95 (EOPNOTSUPP) before the change and passes after; the Connected regression guard passed throughout.

This cluster is a genuine legacy-mode reproducer. Kernel 5.14.0-570.141.1.el9_6.x86_64 rejects SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV with EINVAL, so OpenShell falls back to LegacyReadOnly here. Confirmed identically on the node host and inside an ordinary pod under restricted-v2 with RuntimeDefault seccomp. Probe controls: NEW_LISTENER alone → OK; NEW_LISTENER|TSYNC_ESRCH (1<<4, valid since 5.7) → OK; NEW_LISTENER|(1<<20) → EINVAL. So the probe discriminates correctly.

Correction to Revision 4. Revision 4 claimed RHEL 9.6 had backported the flag and that the cluster therefore could not reproduce the bug. That was wrong: the probe used bit 1<<4, which is TSYNC_ESRCH, not WAIT_KILLABLE_RECV (1<<5, as seccomp_notify.rs:23 correctly defines it). It was measuring an unrelated flag that 5.14 does support. Re-probed with the correct bit; both the host and in-pod results now agree the flag is absent. The "kernels before Linux 5.19" framing in the existing docs is accurate and needs no correction.

Consequence: the forcing harness is no longer needed to validate this fix. Step 3 existed only because no legacy kernel was expected to be available. End-to-end validation can run directly against the real fallback on real hardware, which is strictly better evidence than a synthetic cBPF harness. Step 3 is demoted to optional CI coverage (see below).

This matches the reporter exactly. Their symptom is independently diagnostic: in non-test code, accept() can return EOPNOTSUPP only from the write_socket_addr fail-closed branch (the sole other source, read_sendmsg_message rejecting msg_controllen != 0, is unreachable from accept). Reporter and cluster are now known to be in the same mode.

Steps 4–6 results — shim delivery settled, and two earlier claims corrected

The shim has to live somewhere the workload's dynamic loader can open, map PROT_EXEC, and that the Landlock baseline actually exposes. Settling that produced two corrections to earlier revisions.

Correction 1 — /.openshell cannot host the shim. An earlier option in this thread proposed shipping the object read-only next to openshell-sandbox at /.openshell/runtime/accept_shim.so. That is not implementable. The capability-free Landlock baseline (sandbox/linux/mod.rs:46-67, landlock.rs:170) grants each top-level filesystem entry except .openshell, and the user ruleset can only intersect with the baseline — it can never re-expose the private hierarchy. The omission is deliberate and hardened: the baseline pins the private root with O_PATH|O_NOFOLLOW specifically so a symlink redirect cannot broaden the allowlist, guarded by capability_free_baseline_rejects_private_root_redirect. A workload physically cannot open a file there, so a shim placed there could never be preloaded.

Correction 2 — the workload rootfs is not noexec. An earlier message in this thread implied a container-wide no-exec posture that placing the shim would erode. That described the wrong container. The readonly_rootfs plus noexec tmpfs mounts on /run, /tmp, /var/log at driver-docker/src/lib.rs:4980-5010 belong to the supervisor container. The workload container (:5780-5828) sets no readonly_rootfs and has exactly one tmpfs — the CA material directory, which is noexec and therefore unusable for this. So the workload rootfs is already both writable and exec-capable, and materializing an exec-capable file on it adds no capability the workload did not already have.

Resolution: materialize to /run/openshell-compat/accept_shim.so. Outside .openshell, so the baseline exposes it; outside the noexec CA tmpfs, so it can be mapped; and reusing the install_ca_material_at pattern the sandbox already performs at this location. No driver packaging changes at all — the object is embedded in the openshell-sandbox binary via include_bytes! and written at startup. Directory and file are both sealed to 0o555 after an atomic rename, with symlink and non-directory rejection on both.

Re-validated on the mount the workload actually gets. The earlier OQ-3 result tested /run in an ordinary pod, where it is part of the container's overlay root. The Kubernetes driver does not give the workload that: agent receives /run as an emptyDir{medium: Memory} tmpfs (driver-kubernetes/src/driver.rs:5629-5630). Re-tested against that exact mount on OpenShift 4.21 / RHCOS 9.6, SELinux Enforcing:

Question	Result
emptyDir{medium: Memory} mount options	rw,seclabel,relatime,size=…,inode64 — no noexec
Mount mode	drwxrwxrwt (1777), so a non-root sandbox uid can create its subdirectory
Label of the materialized file	system_u:object_r:container_file_t:s0:c96,c154 — matches the process MCS
Does LD_PRELOAD load from there?	Yes, silently, and /proc/self/maps shows an r-xp mapping of the object
Under runAsNonRoot: 10001 + readOnlyRootFilesystem: true + dropped caps + RuntimeDefault seccomp?	Yes — including the full mkdir → write 0555 → seal dir 0555 install sequence
AVC denials	None. 14 denials in the window, all { search } comm="qemu-ga", unrelated. No execmod, no execute, no map.

The control case (a bogus preload path) emits the expected ERROR: ld.so: … ignored. line in every run, so the negative result is real rather than a silently skipped preload.

One false alarm worth recording, since it would be easy to re-trigger: the first in-cluster attempt failed with cannot open shared object file, which looks like an SELinux denial. It was not. e_machine was 0xb7 (EM_AARCH64) — the container build had run native on an Apple Silicon host while the cluster is x86_64. Rebuilt for the right target and it loaded immediately. Any cross-arch validation must check e_machine before concluding anything about policy.

Implementation is wired and type-checks on Linux. install_object_at lives in the openshell-accept-shim crate (8 tests green, test-first). child_env.rs holds the shim path in a process-global OnceLock plus the LD_PRELOAD composition helpers (3 tests green), matching the existing process-wide ocsf_ctx() convention rather than threading state through three struct hierarchies. Injection is wired at all three env-assembly sites, each respecting that site's ordering: boundary_exec.rs calls env_clear(), so injection goes last, after the spec.env loop; the two process.rs sites do not clear, so they consult configured_user_environment() and then the process environment. Composition is idempotent, so a child re-inheriting the value and spawning its own child does not grow the variable.

Step 4 collapsed. The planned WorkloadLauncher::listener_mode() accessor turned out to be unnecessary: listener.writes_disabled() is already in scope at the live workload_launcher::start() call site in boundary_server.rs, immediately before NetworkBroker::start consumes the listener. One call, no new API.

Corrections to the original analysis

1. The current failure is destructive. accept_and_inject performs the real libc::accept4 at network_broker.rs:1224 before attempting the write. In legacy mode write_socket_addr fails at :1250, the ? returns early, and the already-accepted OwnedFd is dropped. The connection has already been dequeued from the backlog, so it is not refused — it is accepted and then silently closed.

This is diagnostic, not functional: the server receives EOPNOTSUPP either way, so no workload is made to work by fixing it. Its significance is that it explains the confusing field symptom (ReadError('') — an empty read is the signature of connect-then-silently-closed) and that a mediation layer should not destroy connections it has declined to mediate. Tracked separately; not folded into this change.

Its consequence for this plan is a hard constraint: the shim must never attempt an address-bearing accept and fall back on failure — that fallback would be a connection shredder. It must choose its path before issuing any syscall.

2. The "musl aborts on preload failure" risk does not reproduce. Measured on real images with a real exec:

libc	Missing preload	Garbage preload
glibc (Debian 12)	stderr ERROR: line, continues, exit 0	stderr ERROR: line, continues, exit 0
musl (Alpine 3.20)	silent, continues, exit 0	silent, continues, exit 0

Neither aborts. The self-test is therefore retained as cheap defense-in-depth that suppresses a glibc stderr line and guards older loaders, but it is not load-bearing for workload survival.

Coverage

LD_PRELOAD interposes symbols, not syscalls. The broker fix has no such limitation — it applies to every workload regardless of language or linkage.

Runtime	Covered	By what
Bun (node:http)	yes — verified	shim (passes a peer buffer to accept4)
Node / libuv	yes — verified	broker getpeername CONTINUE; needs no shim
CPython	yes	shim (sock_accept passes a buffer, via libc)
Go	accept: no; getpeername: yes	net issues SYSCALL directly, bypassing the shim; the broker fix still reaches it
Static / AT_SECURE binaries	same as Go	no dynamic loader, or preload ignored

Go's accept path remains uncovered. That is a property of the approach, not an edge case, and must be stated plainly in the docs — but note the broker fix does reach Go, so Go is strictly better off than in Revision 2.

Scope

New

• crates/openshell-accept-shim/ — accept_shim.c plus a build.rs that compiles it freestanding and embeds the result. Freestanding C, not Rust: a Rust cdylib would carry a DT_NEEDED on either glibc or musl and be unloadable in the other. The crate also owns install_object_at / install_shim and the LD_PRELOAD composition helpers.

Modified

• network_broker.rs — get_peer_name responds respond_continue for AcceptedLocal and Local. Connected { original_peer } must keep the existing substitution: those sockets really connect to a local relay, so the kernel's answer would leak the relay address. (committed)
• boundary_server.rs — install_peer_address_shim, gated on listener.writes_disabled(), emitting ConfigStateChangeBuilder success/failure per AGENTS.md. Install failure is non-fatal: the shim is a compatibility aid, so the sandbox still starts with the broker's existing fail-closed behavior.
• child_env.rs — shim path storage and LD_PRELOAD composition, shared so the spawn paths cannot drift.
• process.rs (two sites) / boundary_exec.rs — inject via that shared helper, composing with any user-supplied value rather than clobbering it.
• scripts/update_license_headers.py — add .c/.h to COMMENT_STYLES, or license:check silently skips the new sources.
• docs/about/support-matrix.mdx, docs/kubernetes/openshift.mdx.

No longer needed (planned in Revision 5, dropped):

• workload_launcher.rs mode accessor — superseded by listener.writes_disabled() at the call site.
• process.rs Landlock ca_runtime_read_only_paths extension — the capability-free baseline already grants /run; only .openshell is withheld.

Deliberately not modified: the Kubernetes, Docker, Podman, and VM drivers, and Dockerfile.sandbox. The shim is embedded in the openshell-sandbox binary and materialized at startup.

Implementation Steps

1. Build the shim; prove it loads under glibc and musl. Done — see Step 1 results.
2. Broker getpeername CONTINUE for AcceptedLocal/Local. Done — committed. Fixes Node on its own.
3. Legacy-mode forcing harness — demoted to optional. A cBPF filter in a disposable child returning EINVAL for seccomp(SET_MODE_FILTER) when WAIT_KILLABLE_RECV is set. Off the critical path now that a real legacy kernel is available; its remaining value is giving CI runners on modern kernels any legacy coverage at all. Deferred unless the e2e lane needs it, since the Step 2 unit tests already pin legacy behavior deterministically by constructing a LegacyReadOnly listener directly.
4. Expose the mode from WorkloadLauncher. Dropped — unnecessary. See Step 4–6 results.
5. Materialize the shim. Done. /run/openshell-compat, 0o555, atomic, symlink-rejecting; validated against the real Kubernetes mount under SELinux enforcing.
6. Inject LD_PRELOAD at all spawn paths, gated on legacy mode. Done. Linux cargo check green.
7. End-to-end on the OpenShift cluster — against the real LegacyReadOnly fallback, not a harness. Next.
8. Docs.

Test Plan

• Unit:
  • get_peer_name: AcceptedLocal responds CONTINUE; Connected still substitutes original_peer (regression guard against leaking the relay address — the security-relevant assertion); unknown fd still CONTINUEs; non-connected states still ENOTCONN. The existing legacy_listener_rejects_socket_addr_write test covers both accept and getpeername today and must be split so the accept half keeps asserting the refusal. (done)
  • Materialization: symlink-directory reject, symlink-target reject, mode 0o555, idempotent replacement. (done)
  • LD_PRELOAD composition: preserves a workload value, is idempotent across nested spawns, workload value wins over the sandbox's own. (done)
  • Shim truncation/family matrix — capacity 0 / 8 / 16 / 28 / sizeof(sockaddr_storage) against AF_INET, AF_INET6, v4-mapped, each asserting *addrlen carries the true length even when truncating.
• Integration: a plain-loopback LD_PRELOAD test with no seccomp at all. Landlock tests: a sandboxed child can map the shim, cannot write it, and fails to load it when the path is absent.
• E2E (Step 7, on the legacy-kernel cluster): assert (a) an address-bearing accept succeeds and reports the true peer port, not the listener's — the specific wrong answer measured in Step 2; (b) a Node-style accept(NULL) + getpeername sequence returns the true peer; (c) a second connection from the same client still works. Use distinct probes so the two mechanisms are isolated: CPython socket.accept() exercises the shim, Node remoteAddress exercises the committed broker fix alone. Control case on a Killable-mode host asserting LD_PRELOAD is absent. Static-binary and musl workloads asserting graceful degradation.
• Manual (OpenShift, SELinux enforcing): confirm seccomp_listener_mode is legacy_read_only, no AVC denials on the shim path, and opencode serves loopback traffic.

Risks & Open Questions

• OQ-1 build toolchain — resolved. zig 0.14.1 already pinned; both arches build and run.
• Peer port reported as 0 — resolved by the broker fix. The shim calls getpeername, yielding full peer fidelity.
• OQ-2 (Step 7): the cBPF prelude works in-process in Rust tests, but e2e runs a released image whose entrypoint is openshell-sandbox. Preference is a test-only helper in the e2e image that installs the prelude and execs the real entrypoint. Explicitly rejected: an env var forcing legacy mode in production builds — that is a mediation-downgrade primitive. Lower priority now that the cluster reproduces legacy mode natively.
• OQ-3 /run labeling and noexec under container_t — resolved, and re-verified against the correct mount. The Kubernetes workload gets /run as an emptyDir{medium: Memory} tmpfs, not the overlay root tested in Revision 4. Re-tested on that mount: no noexec, container_file_t with matching MCS, r-xp mapping granted, works as a non-root uid with readOnlyRootFilesystem and dropped caps, zero related AVC denials.
• OQ-4 is SocketState::Local { peer } also safe to CONTINUE? — resolved: yes. Local is set only after connect_exact(fd, destination) connects directly to the loopback destination with no relay, so the kernel's peer equals the recorded one. Contrast Connected, set after connect_exact(fd, relay_address) against a local TcpListener. Both states are covered by the Step 2 test.
• OQ-5 (open): registration ordering. accept_and_inject calls add_fd_and_send — which resumes the workload — before commit_with_state. A fast shim could therefore call getpeername before the socket is registered. If resolve fails there we fall through to respond_continue, which is the correct answer for this fd, so the race looks benign. Still to be confirmed rather than assumed — to be closed before the PR.
• OQ-6 (new): shim path collision. /run/openshell-compat is created by the sandbox at startup. If a workload image already ships a file or symlink there, installation refuses rather than overwriting, and the sandbox proceeds without the shim — degraded but safe. Worth asserting explicitly in a test.
• CONTINUE security analysis. getpeername is read-only and creates no descriptor, so CONTINUE here is materially safer than CONTINUE for accept (rejected, because the resulting fd would bypass the registry). Residual race: another thread could dup2 over the fd number between notification and kernel execution, causing the kernel to answer for a different socket. The workload can only mislead itself — it cannot reach a socket it does not already hold — and register tampering is excluded because ptrace is in the child_seccomp KILL list.
• Partial coverage by design — see the coverage table. Go's accept path is not fixed.
• The shim is not a security control and nothing may trust it. The broker's loopback enforcement uses the kernel's own peer from its own accept4; the shim's output never re-enters OpenShell's trust domain. A workload can unset LD_PRELOAD, link statically, or issue raw syscalls and gain nothing it did not already have. This is why its location carries no privilege weight — the real boundary remains the broker's fail-closed behavior.

Documentation Impact

• docs/about/support-matrix.mdx — rewrite the legacy read-only section: remove address-bearing accept and getpeername from the unsupported list, drop the port-0 caveat, add the coverage table. The existing "kernels before Linux 5.19" predicate is accurate and stays. Add that RHCOS 9.x / RHEL 9.x land in this mode, since that is the platform the reporter and the test cluster are both on.
• docs/kubernetes/openshift.mdx — preserve the #legacy-read-only-mode-kernels-before-linux-519 anchor.
• crates/openshell-accept-shim/README.md — design rationale, the "not a security control" statement, the /run/openshell-compat placement and why not /.openshell, no-panic/no-alloc invariants.
• No gateway configuration doc change. No skill updates expected (re-verify at PR time). test:windows not required.

---

Revision 6 — settles shim delivery. Corrects two claims made earlier in this thread: /.openshell cannot host the shim (the capability-free Landlock baseline deliberately withholds it and is hardened against symlink redirects), and the workload rootfs is not noexec (that posture belongs to the supervisor container). Shim now materializes to /run/openshell-compat, needing no driver packaging changes. OQ-3 re-validated against the mount the Kubernetes workload actually gets — a memory emptyDir, not the overlay root — including as a non-root uid under SELinux enforcing with zero AVC denials. Steps 5 and 6 implemented and type-checked on Linux; Step 4 dropped as unnecessary. Adds OQ-6.
Revision 5 — corrects Revision 4's kernel finding. The earlier probe tested bit 1<<4 (TSYNC_ESRCH), not WAIT_KILLABLE_RECV (1<<5). Re-probed correctly on both host and pod: RHEL 9.6 does not have the flag, so the cluster really is LegacyReadOnly and reproduces the reported bug natively. The docs' "before 5.19" wording is correct after all. Step 3's forcing harness drops off the critical path — e2e can run against the real fallback.
Revision 4 — Step 2 implemented and committed (test-first: RED at errno 95, then GREEN). OQ-3 resolved on a live SELinux-enforcing OpenShift cluster. OQ-4 resolved (Local connects directly, so CONTINUE is safe). In-cluster run reproduced the getsockname port hazard, confirming the Revision 3 switch to getpeername. Found that RHEL 9's 5.14 backports WAIT_KILLABLE_RECV, so the docs' "kernels before 5.19" predicate is wrong and the cluster cannot reproduce the bug without the forcing harness.
Revision 3 — scope expanded to getpeername after tracing Node: libuv passes NULL to accept4 and resolves the peer lazily, so Node is fixed by a broker-side respond_continue for AcceptedLocal rather than by the shim. Retires the port-0 caveat (the shim can now call getpeername), extends coverage to Go's getpeername path, and adds OQ-4/OQ-5.
Revision 2 — Step 1 complete: toolchain and portability proven on both arches and both libcs; approach validated end to end against Bun/opencode; corrected the musl hard-abort risk (does not reproduce); added coverage table; recorded port-zeroing evidence.
Revision 1 — initial plan

[russellb]

🏗️ build-from-issue-agent

Implementation is up in #4087.

Workloads that accept connections now get the connecting peer's address on kernels that lack SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV (Linux < 5.19, including RHEL 9.x and RHCOS), instead of failing with EOPNOTSUPP. getpeername on a directly connected socket now reports the real peer on every kernel and every runtime.

Verified end to end on affected hardware: an OpenShift cluster running RHCOS 9.6 (kernel 5.14.0-570.141.1.el9_6.x86_64). A sandbox whose listener accepts a connection from a client in the same sandbox now reports the client's address correctly; before the change the same workload got errno 95.

Scope worth knowing before you test:

• Python and Bun are covered.
• Node.js never needed the fix for accept — libuv passes a null address and resolves the peer lazily — but it does benefit from the getpeername correction.
• Go and statically linked binaries are still unsupported for address-bearing accept, because the compatibility layer works by interposing libc symbols. Their getpeername is fixed, since the kernel answers that one directly.

This is a compatibility aid, not a security control. OpenShell does not trust its output: loopback and authorization decisions still use the kernel's own peer address.