MGS2010: sandbox weakened
A magus started inside a sandboxed run, or a run forwarded to a server, asked for a sandbox mode weaker than the one it runs under. magus refuses it before running anything.
[MGS2010] this magus, started inside a sandboxed run, asked for sandbox mode off, weaker than the best-effort it runs under; a nested or forwarded run may only strengthen the sandbox
[MGS2010] a forwarded run asked for sandbox mode off, weaker than the required it runs under; a nested or forwarded run may only strengthen the sandbox
Why
The modes are ordered off < best-effort < required. A sandboxed run hands
every child its mode in MAGUS_SANDBOX, the sandbox.mode setting's own variable
and a floor rather than an override, so a nested magus runs under the stronger of
that mode and its own workspace's without doing anything. Only a flag could lower
it, and a flag written by the code the sandbox confines is
exactly what the sandbox must not obey. So a nested magus may pass --sandbox to
move up the order and never down.
A forwarded run is the same question asked across the proc socket. A client tells the server the mode it runs under, and the server runs the work under its own workspace's mode. A client flag asking for less than either is refused here. A client whose mode the server's workspace does not meet is not an error: the server declines the run and the client runs it itself, under its own mode.
Resolution
- Drop the
--sandboxflag from the nested or forwarded command, or raise it to the mode named in the message or above. - To run a nested magus with less confinement, change the parent: run the outer command under the weaker mode. A child cannot shed its parent's sandbox.