The problem
brokerclient.policyFields exists to refuse a create request that carries a policy option, rather than silently dropping it — the daemon's profile owns isolation, and a caller that thinks it asked for something it did not get is the exact failure openbloxd is built to prevent. Its own doc comment says so.
It cannot do that in one case: a policy option explicitly set to the library's default value is indistinguishable from that option never being passed.
WithRuntime, WithEgress and the resource options are applied into a sandbox.Spec before brokerclient inspects anything. By the time inspection happens, all it can see is the resolved struct. An option set to the zero or default value leaves the struct identical to one where the caller passed nothing, so the request is accepted and the option is dropped in favour of the profile.
Why isolation is unaffected
Daemon policy still wins in every case. There is no configuration where this results in weaker isolation than the profile specifies — the field is discarded, not honoured. The defect is one of honesty, not of enforcement: the caller is not told that something it explicitly asked for was ignored.
Why it is not a small fix
Detecting it requires tracking option intent — that a caller called WithRuntime at all — separately from the resolved value. sandbox.CreateOption cannot express that today: an option is a function that mutates a Spec, and mutation to a default value leaves no trace.
Plausible directions, none free:
- Have
CreateOption record which fields it touched, alongside applying them. Changes a public type.
- Have
brokerclient accept its own option type rather than reusing sandbox.CreateOption, so policy options are unrepresentable rather than rejected at runtime. Arguably the better end state — making a mistake impossible beats detecting it — but it is a second option vocabulary to maintain.
Acceptance
A caller that explicitly passes a policy option is told, whether or not the value it passed happens to equal the library default.
The problem
brokerclient.policyFieldsexists to refuse a create request that carries a policy option, rather than silently dropping it — the daemon's profile owns isolation, and a caller that thinks it asked for something it did not get is the exact failure openbloxd is built to prevent. Its own doc comment says so.It cannot do that in one case: a policy option explicitly set to the library's default value is indistinguishable from that option never being passed.
WithRuntime,WithEgressand the resource options are applied into asandbox.Specbeforebrokerclientinspects anything. By the time inspection happens, all it can see is the resolved struct. An option set to the zero or default value leaves the struct identical to one where the caller passed nothing, so the request is accepted and the option is dropped in favour of the profile.Why isolation is unaffected
Daemon policy still wins in every case. There is no configuration where this results in weaker isolation than the profile specifies — the field is discarded, not honoured. The defect is one of honesty, not of enforcement: the caller is not told that something it explicitly asked for was ignored.
Why it is not a small fix
Detecting it requires tracking option intent — that a caller called
WithRuntimeat all — separately from the resolved value.sandbox.CreateOptioncannot express that today: an option is a function that mutates aSpec, and mutation to a default value leaves no trace.Plausible directions, none free:
CreateOptionrecord which fields it touched, alongside applying them. Changes a public type.brokerclientaccept its own option type rather than reusingsandbox.CreateOption, so policy options are unrepresentable rather than rejected at runtime. Arguably the better end state — making a mistake impossible beats detecting it — but it is a second option vocabulary to maintain.Acceptance
A caller that explicitly passes a policy option is told, whether or not the value it passed happens to equal the library default.