Description
Each use of --seccomp overwrites the same variable used for previous uses. This has two problems:
- Least-astonishment: a user might reasonably expect repeating the option to work.
- Some uses of libseccomp are not possible to do with a single seccomp program (they would be possible in raw BPF, but nobody wants to write that when libseccomp can do half the work for us) so it would be useful to be able to add more than one ruleset from separate fds (e.g. see Handle syscalls via allowlist instead of denylist flatpak/flatpak#4462, where I tried to do this).
To solve the first problem, I think bwrap --seccomp 23 --seccomp 42 should print a warning indicating that fd 23 is ignored and only fd 42 is used. Making it a fatal error might even be justifiable, but that could be considered to be a compatibility break.
To solve the second problem, I think the safest way would be to add a new --add-seccomp-fd option that can be used by callers that want to be able to rely on it (instead of risking --seccomp silently not doing what they expect if there is a version mismatch). It could build up a linked list of seccomp programs or something. For bug-for-bug compatibility, --seccomp would perhaps empty the list, and then append.
Activity