On Fri, Jun 12, 2026 at 8:25 PM Will Drewry <[email protected]> wrote: > > So I have two concerns here -- > > 1. By layering, STRICT becomes subject to FILTER RET behaviors. > 2. If we did want to layer them, it would be ideal to separate the 'upgrade' > decision from the access checks and make the layering path explicit. > > If you are running a legacy binary that uses STRICT in Docker, then I > understand the goal, but there are userspace options. > > I think it's hard to want to open the door on changing STRICT without > a good reason to work through all the implications that come with it: > cross-checking every SECCOMP_MODE_FILTER reference, sorting > out thread sync interactions, ... > > That said, this change could be streamlined and look for ways > to minimize any potential implications. > > Am I missing something or overstating it? > > Thanks!
Thanks for the review - I'm currently working on a new version which addresses some of the implementation issues. On the semantics side: The current version runs strict checks before filters. I think it makes more sense to run filters, run strict checks, then return the filter result (assuming strict checks were survived) Since the strict checks logically work as another filter layer, documentation says > Synchronization will fail if another thread in the same process is in > SECCOMP_MODE_STRICT So refusing to sync threads which are using both modes seems the most reasonable.
