Skip to content

RFE: non-repeatable options should warn if repeated? #454

Closed
@smcv

Description

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions