Repository navigation
control: process-wide switch to disable registration - #333
Merged
Merged
Conversation
congwang-mk
force-pushed
the
control-disable-registration
branch
from
October 30, 2026 04:09
5debf42 to
7642cc9
Compare
Add registration(false) on SandboxBuilder to configure individual sandbox instances. Unregistered instances skip the name claim, control socket, and control loop without changing other sandboxes in the same process. Names still set the virtual hostname, and direct lifecycle control works. Registration defaults to enabled, including through clap, and stays out of serialized policy. Clones retain the instance setting. Tests cover mixed registration with and without a supervisor, duplicate names, cloning, policy deserialization, and the clap default. Refs #317. Signed-off-by: Cong Wang <cwang@multikernel.io>
Add sandlock_sandbox_builder_registration so C callers and SDK bindings can disable registration for individual sandbox instances. Regenerate the C header for the builder setter. Refs #317. Signed-off-by: Cong Wang <cwang@multikernel.io>
Expose Sandbox(registration=False) as a runtime setting and forward it to the native builder. Registration remains enabled by default. Test that registered and unregistered sandboxes coexist in one process, with duplicate-name checks retained for registered instances. Refs #317. Signed-off-by: Cong Wang <cwang@multikernel.io>
Add Sandbox.DisableRegistration and forward it to the native builder. The zero value keeps registration enabled. Exclude the runtime setting from JSON serialization. Test registered and unregistered sandboxes in one process, including name reuse and registered-instance collision checks. Refs #317. Signed-off-by: Cong Wang <cwang@multikernel.io>
Document the Rust, C, Python, and Go instance settings, their enabled default, and their exclusion from serialized policy. Explain that unregistered instances give up discovery, control by name, and UID-wide name reservation while retaining virtual hostnames and direct control. Closes #317. Signed-off-by: Cong Wang <cwang@multikernel.io>
congwang-mk
force-pushed
the
control-disable-registration
branch
from
October 30, 2026 04:12
7642cc9 to
f1e2148
Compare
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
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.
Closes #317.
Why
Every sandbox claims its name in the per-user SysV registry and binds an abstract control socket, even in embedders that never use
sandlock ps. Each spawn takes a UID-wide registry lock, and any process of the same user can list the embedder's sandboxes, read their effective policy through theconfigverb, and kill them. Whether to register is the host program's call and the same for every sandbox it runs, so this is a process-wide switch rather than a policy field (the per-sandbox knob was removed in 9c1981b).What
sandlock_core::control::disable_registration(). Every later spawn skips the name claim, the control socket and the control loop..name()still sets the virtual hostname;Controllerand pidfd-based control are unaffected. The switch is one-way, so a process never ends up half registered by accident, and the best-effort fallback for a failed bind is unchanged.sandlock_disable_registration(), header regenerated.sandlock.disable_registration(). go:DisableRegistration().ps,killby name, and UID-wide name uniqueness.The CLI is unchanged and stays registered. A
--unregisteredflag would be consistent with the scoping (one CLI invocation is one process) and can follow if someone needs it.Tests
Because the switch is process-wide, each test runs in its own process:
crates/sandlock-core/tests/registration_disabled.rs.python/tests/test_registration.pyruns in a child interpreter.TestDisableRegistrationFreesNamesre-executes the test binary.Each starts a long-running sandbox and a second one with the same name, which fails with "already running" when registration is on. The Rust test also checks the name is absent from
list_sandboxes(). The Rust and Go tests were confirmed to fail without the call. Existingtest_controlintegration tests: 34 passed.🤖 Generated with Claude Code