[PATCH RFC 2/2] seccomp: implement SECCOMP_FILTER_FLAG_NO_INHERITANCE

Paul Chaignon paul.chaignon at gmail.com
Mon Nov 18 20:28:22 UTC 2019


On Mon, Nov 18, 2019 at 11:23:15PM +0300, Dmitry V. Levin wrote:
> On Mon, Nov 18, 2019 at 08:17:38PM +0100, Paul Chaignon wrote:
> > On Mon, Nov 18, 2019 at 10:11:29PM +0300, Dmitry V. Levin wrote:
> > > On Mon, Nov 18, 2019 at 08:02:48PM +0100, Paul Chaignon wrote:
> > > > On Mon, Nov 18, 2019 at 09:39:41PM +0300, Dmitry V. Levin wrote:
> > > [...]
> > > > > Why can't we have only some of seccomp filters to be NO_FORK_INHERIT'ed?
> > > > 
> > > > If we have filter list f1->nf2->f3, with only nf2 NO_FORK_INHERIT'ed, we
> > > > would need to make a copy of at least f1 upon forking to rewrite its .prev
> > > > pointer to point to f3 directly.  Currently, children get a reference to
> > > > the list, there's no need for any filter copy.
> > > 
> > > OK, we might need to make a copy, is it a problem?
> > 
> > We'll need to copy all of the filters before any NO_FORK_INHERIT'ed
> > filter.
> 
> Why?  If I understand correctly, only those filters that were added after
> the strace's NO_FORK_INHERIT'ed one would have to be copied.

Oh, yes, that's what I'm saying.  In the list, those filters are before
the NO_FORK_INHERIT'ed one.  If we add f1, then f2, then f3, we get a
seccomp filter list f3->f2->f1.  So if f1 is NO_FORK_INHERIT'ed, we need
to copy both f2 and f3.

Paul


More information about the Strace-devel mailing list