Paul Chaignon's GSoC status report - #4 of 12

Paul Chaignon paul.chaignon at gmail.com
Tue Jun 25 09:27:50 UTC 2019


On Tue, Jun 25, 2019 at 03:48:46AM +0300, Dmitry V. Levin wrote:
> On Mon, Jun 24, 2019 at 09:12:12PM +0200, Paul Chaignon wrote:
> [...]
> > - While going through the patched test suite (see previous GSoC report), I
> >   noticed that several tests with fork() or threads but without the -f option
> >   were failing.  These are failing because children tasks inherit the seccomp
> >   filter of parent tasks.  Thus, if tracing a multi-task process with strace -n
> >   (i.e., seccomp filtering enabled), we should make sure that -f is enabled so
> >   that all tasks have a proper tracer.  The current patchset errors out when -n
> >   is given without -f.  While this propagation of seccomp filters to children
> >   tasks makes sense for sandboxing, it might be worth having an option in the
> >   kernel to disable propagation for tracing use cases.  Without such an option
> >   in the Linux API, strace will only be able to use seccomp filtering when -f
> >   is set.  What do you think?  Should I send an RFC patch to the kernel after
> >   my main seccomp tasks are finished?
> 
> What kind of Linux API change do you have in mind?
> A new SECCOMP_FILTER_FLAG_* flag for SECCOMP_SET_MODE_FILTER?

Yes.  I haven't look into it, so I don't know what the implementation would
look like yet (nor do I have a good name for the flag).

Paul


More information about the Strace-devel mailing list