Paul Chaignon's GSoC status report - #4 of 12
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).
More information about the Strace-devel