You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e1ef863
Browse filesBrowse the repository at this point in the historyBrowse files
Reject an unenforceable allowLocalNetwork deny on value, not on presence
allowLocalNetwork=false under a shared namespace is refused at 0.8 because
Bubblewrap cannot deliver the deny. That refusal was gated on a parse-time
allow_local_network_specified flag, so it fired only for callers who wrote
the field. false is the schema default *and* a deny, so an omitted field is
still a request for inbound denial: a bare defaultPolicy='allow' ran with
the deny silently unenforced. Default-deny is the contract, and a backend
that cannot honor a restriction refuses it rather than choosing
default-allow on the caller's behalf.
IsolationSession already takes the strict reading of this exact field:
validate_provision_network_policy requires allow_local_network by value and
refuses an absent policy as "a restriction the backend cannot honor". The
guard is now dropped so Bubblewrap agrees, and the flag it existed for goes
with it -- that guard was its only production consumer, so models.rs and
network_parser.rs leave this change with no net diff.
The rejection stays actionable: a shared namespace is still reachable by
acknowledging the exposure with allowLocalNetwork=true, which the error text
now names. No existing config changes behavior -- both shared-namespace
corpus configs set the field explicitly, and every other 0.8 Bubblewrap
config resolves to a private namespace via a proxy or host rules.
Coverage: the guard had none. Deleting it outright left all 202 tests
passing, because the one test that looked like it covered this used
defaultPolicy='block', whose private namespace short-circuits the mode arm.
Two unit tests now pin the omitted and acknowledged cases (204 total; a
reintroduced guard fails three), and two e2e configs pin them end to end,
the acknowledged one asserting the sandbox really is in the host netns so
"reject the deny" cannot be satisfied by refusing every shared-namespace
request.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: ae9db9df-6439-46c3-9cb4-fd70e7cc43a3
0 commit comments