Repository navigation
Conversation
added 30 commits
September 29, 2026 21:41
Stand-in invocations ran concurrently (a foreground `up` while the driver polls `ps`) and each did an unlocked read-modify-write of state.json. A `ps` that loaded the state before the second `up` saved its foreground token then saved its stale copy over it, so `up` saw its token gone and exited 0 before readiness; lost call records failed the acceptance test as well. That failed 26 of 40 local runs, and Runtime state models on CI. Each invocation now holds an exclusive flock across its read-modify-write and releases it only before its long waits (the foreground loop and the ps-hang fault). 40 of 40 local runs pass.
A review of #109 found two startup ownership gaps. The native HTTPS owner discarded the identity listenPublishedUnixSocket returned and only recorded one after lstat, chmod and lstat of the path. A failure after publication then skipped listener and endpoint cleanup, and a replacement in that window could be chmodded or recorded as the endpoint. The owner now keeps the published identity at once, compares its first observation against it, and never changes the endpoint by path. Failure cleanup always closes the listener, which can no longer unlink anything but the retired staging name, and then removes the endpoint only while it is this listener's inode; a replacement is kept. The helper awaited listen() outside its cleanup, so a listen that bound the staging name and then failed could leak that socket and listener. Listening is now inside the cleanup, and a failed start removes only a staging socket this user created. The helper also sets the endpoint mode (0600) on the staging inode before publication, so the MCP backend, the HTTPS owner and the owner challenge no longer chmod the public path. Controls: bind-then-fail, mode-preparation failure, an endpoint at the AF_UNIX path limit (and one byte over: refused cleanly on Bun 1.3.9, bound in full on 1.4.2, never truncated), and an owner fault or replacement between publication and first observation, on Bun 1.3.9 and 1.4.2.
The private-bind fixture hooked chmod on the public mcp.sock to prove the socket is private before its mode is set and that the creation mask is restored. Since the endpoint's mode is now set on its staging socket before publication, the hook never fired and the check failed. It now observes that staging chmod with the same privacy and mask checks, requires mode 0600, and fails if the published endpoint is ever chmodded by path.
…a socket A second review of the Unix-socket publication found three staging-path windows where an entry this attempt could not prove was its own could be changed or removed: - After an ambiguous partial bind (no recorded identity), cleanup unlinked any same-uid socket at the staging name. - The mode was set by path after an awaited lstat, so a replacement in that gap could be chmodded before the postcheck refused it. - On success the staging name was unlinked unconditionally after the awaited link and endpoint lstat. The socket is now created with exactly its mode (the umask during the synchronous bind), so nothing is ever chmodded, and its identity is recorded in the same tick. Publication links only while the staging name is still that socket, and retirement removes it only while it is (check and removal back to back). An entry that is not this socket, or cannot be proven to be, is never removed: on failure it is moved aside while the server closes, so the runtime's close-time unlink by name cannot reach it, and then put back with the same inode. The owner challenge's chmod dependency becomes an afterOwnerSocketPublish test seam, and the private-bind fixture now requires the socket to be created private with mode 0600 and no socket name to be chmodded.
…ng entry The failure close moved an unproven staging entry to one random holding name: if that name was occupied the close went ahead unprotected, and a holding entry created between the check and the rename was overwritten. The entry is now moved with link(2), which never replaces a holding entry, over a bounded list of fresh holding names, and the staging name is dropped only while it is still the linked entry. An entry that cannot be moved aside (every holding name occupied, or not hard-linkable) leaves the close to proceed, now documented as a residual. The helper's documentation now states its scope: accidental and concurrent entries in a private directory, not an adversarial process of the same user, with the remaining path-based and post-return residuals.
added 3 commits
September 30, 2026 15:26
Add explicit selector-bound recovery for a dead legacy HTTPS owner beside an unpublished shared-owner configuration. Preserve original inodes and the CA with resumable exclusive archival, held IPv4/IPv6 guards, and refusal on live or uncertain evidence.
Keep strict receipt identities as the default. Allow only an explicitly selected source-device witness and both current HTTPS inodes, with unchanged inode numbers and matching old/current device mapping. Recheck current owner, host and guest boot, source share and stopped graph scope before archival; preserve historical bytes and report original host-volume continuity as unproven.
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Restarting a graph in its already running, owned development VM was charged the disk budget of a second VM. A host with enough reserve could therefore fail admission before graph cleanup even though startup would reuse the existing storage and overlay.
Development admission now uses the existing 16 GiB host reserve only after verifying the exact running owner, process/PID-file identity, machine name, and both disk identities and declared sizes. New capacity keeps its 58 GiB budget. Memory, pressure and thermal checks are unchanged. Ownership is rechecked during sampling and after the startup lease; reduced-budget requests cannot enter VM create or boot. The probe reports which budget applies.
Validation: five focused ownership/refusal tests; default Rust suite (1,009 passed, 62 ignored); all-feature suite (1,098 passed, 84 ignored); strict Clippy for both feature sets. A fresh signed bundle on the retained M3 pool verifies all six manifest entries and both executable signatures. Its probe admits the independently verified running pool at the 16 GiB reserve while the previous build rejects the same pool under the 58 GiB allocation budget. VM/process, disk identities, CA and application checkout remain unchanged. Normal restart now passes that resource gate but separately refuses active graph selection for an already stopped graph; that follow-up is being addressed on a separate branch. Fresh application/browser acceptance remains open.
This branch includes the current recovery integration from #118 and targets
next. It does not qualify whole-product parity, browser acceptance, lower resource usage or prerelease readiness.