bubblewrap: Add --not-a-security-boundary flag to enable fail-open behavior#751
Draft
ao2 wants to merge 1 commit into
Draft
bubblewrap: Add --not-a-security-boundary flag to enable fail-open behavior#751ao2 wants to merge 1 commit into
--not-a-security-boundary flag to enable fail-open behavior#751ao2 wants to merge 1 commit into
Conversation
ao2
changed the title
--not-a-security-boundary flag to enable fail-open …--not-a-security-boundary flag to enable fail-open behavior
Contributor
Author
|
cc @smcv even though it's still a draft |
smcv
reviewed
May 7, 2026
Comment on lines
+925
to
+926
| * Maybe we want to handle opt_not_a_security_boundary inside bind_mount | ||
| * itself? |
Collaborator
There was a problem hiding this comment.
Yes, I think that would be a better place to do it.
Contributor
Author
There was a problem hiding this comment.
v2 now splits the logic in two parts:
- To what operation we want to apply the new "fail open" behavior? In
bubblewrap.c - To what step of
bind_mountto we want to "fail open"? Inbind_mount.c
The new version seems more robust, even though I am not sure I like printing the warn() directly in bind_mount().
…behavior Some callers of bwrap (e.g. xdg-dbus-proxy, Steam Runtime) use it purely to adjust filesystem layout, without any expectation of a security boundary between the sandbox and the host. For these callers, hard failures during sandbox setup (such as an automount timeout on a bind source) are unnecessarily fatal. So add a new `--not-a-security-boundary` option that can be used to relax the bubblewrap behavior in these specific cases, and allow it to "fail-open". In the first implementation enable the "fail open" behavior only to the case where bwrap fails to remount a submount with different flags during a `--bind` or `--bind-fd` operations, and still "fail close" for operations like `--dev-bind` and `--ro-bind` which are supposedly more critical. Signed-off-by: Antonio Ospite <antonio.ospite@collabora.com>
ao2
force-pushed
the
ao2/not-a-security-boundary
branch
from
e64137e to
418a4f1
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
2 participants
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.
Some callers of bwrap (e.g. xdg-dbus-proxy, Steam Runtime) use it purely to adjust filesystem layout, without any expectation of a security boundary between the sandbox and the host.
For these callers, hard failures during sandbox setup (such as an automount timeout on a bind source) are unnecessarily fatal.
So add a new
--not-a-security-boundaryoption that can be used to relax the bubblewrap behavior in these specific cases, and allow it to "fail-open".