The Linux sandbox rebuilds mount plans defensively and refuses when it can't verify a path.
What's wrong with this entry?
The Linux sandbox rebuilds its mount plan with a new builder that tracks both the literal and the resolved form of every path and refuses to proceed when it cannot verify what it is about to mount. Fewer overlapping or symlinked paths can open a hole in a sandboxed run.
- Existing ancestor directories are pinned with
--bind, then each pin component is re-checked; a pin is dropped if its component vanished or turned into a symlink, and the whole plan fails if a component cannot be inspected at all. - Write-path and read-allow restores are skipped when they would bury a read-deny mount, and read-allow restores are skipped for symlinks that resolve outside the expected location.
- Read-deny layers that a write-deny bind re-exposed are re-applied on top.
- Linux only.
Refusing to build a mount plan with unverifiable pin components.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.236
macOS sandbox re-applies read and delete denials inside writable folders
Both mention sandbox
-
v2.1.236
Sandbox proxy no longer writes to sockets that have gone away
Both mention sandbox
-
v2.1.236
IPv6 hosts through the proxy
Both mention sandbox