-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: non-repeatable options should warn if repeated? #454
Comments
smcv
added a commit
to smcv/bubblewrap
that referenced
this issue
Oct 10, 2021
A user might reasonably expect that `bwrap --seccomp 3 --seccomp 4 ...` would load seccomp programs from both fds 3 and 4, but in fact it only loads the program from fd 4. Helps: containers#453 Resolves: containers#454 Signed-off-by: Simon McVittie <smcv@collabora.com>
You might also reasonably expect that |
smcv
added a commit
to smcv/bubblewrap
that referenced
this issue
Oct 10, 2021
A user might reasonably expect that `bwrap --seccomp 3 --seccomp 4 ...` would load seccomp programs from both fds 3 and 4, but in fact it only loads the program from fd 4. Helps: containers#453 Resolves: containers#454 Signed-off-by: Simon McVittie <smcv@collabora.com>
brandsimon
pushed a commit
to brandsimon/bubblewrap
that referenced
this issue
Mar 19, 2023
A user might reasonably expect that `bwrap --seccomp 3 --seccomp 4 ...` would load seccomp programs from both fds 3 and 4, but in fact it only loads the program from fd 4. Helps: containers#453 Resolves: containers#454 Signed-off-by: Simon McVittie <smcv@collabora.com>
CrackerCat
pushed a commit
to CrackerCat/bubblewrap
that referenced
this issue
Jul 31, 2024
A user might reasonably expect that `bwrap --seccomp 3 --seccomp 4 ...` would load seccomp programs from both fds 3 and 4, but in fact it only loads the program from fd 4. Helps: containers#453 Resolves: containers#454 Signed-off-by: Simon McVittie <smcv@collabora.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some
bwrap
options cannot usefully be repeated: they overwrite the same variable repeatedly.For
--seccomp
see #453.Options like
--unshare-uts
and--clearenv
are obviously idempotent, so it makes sense for them to succeed silently if repeated.For
--cap-add
and--cap-drop
the meaning is specifically documented, so that seems fine.--userns
,--userns2
,--pidns
,--uid
,--gid
,--hostname
,--exec-label
,--file-label
would make no sense to repeat (the overwriting semantic is the only thing that could possibly work), so they should maybe warn if repeated.--sync-fd
,--block-fd
,--userns-block-fd
,--info-fd
could reasonably be assumed to be repeatable, but actually they're not. As with #453, I think repeating the non-repeatable option should print a warning. Or repeating these options could be a fatal error, but that could conceivably be a backwards-compat break, so perhaps best not.It might also be nice to make the options like
--sync-fd
repeatable (keep more than one fd open while the sandbox is running, etc.). As with #453, I think the safest way to do that would be a new option like--add-sync-fd
, etc. rather than changing the semantics of the existing options. However, I think it's only worth doing that if duplicating the action is genuinely useful.The text was updated successfully, but these errors were encountered: