Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [PATCH 5/7] seccomp_filter: Document what seccomp_filter is and how it works. | From | Eric Paris <> | Date | Wed, 04 May 2011 11:54:22 -0400 |
| |
On Wed, 2011-05-04 at 08:16 -0400, Steven Rostedt wrote: > On Tue, 2011-05-03 at 03:47 +0200, Frederic Weisbecker wrote: > > 2011/5/3 Frederic Weisbecker <fweisbec@gmail.com>: > > > Even better: applying a filter would always automatically be an > > intersection of the previous one. > > > > If you do: > > > > SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2" > > SECCOMP_FILTER_APPLY > > SECCOMP_FILTER_SET, __NR_foo, "b == 2" > > SECCOMP_FILTER_APPLY > > SECCOMP_FILTER_SET, __NR_foo, "c == 3" > > SECCOMP_FILTER_APPLY > > > > The end result is: > > > > "(a == 1 || a == 2) && b == 2 && c == 3" > > > > I'm a little confused. Why do we have both a FILTER_SET and a > FILTER_APPLY? Maybe this was discussed earlier in the thread and I > missed it or simply forgot. > > Why not just apply on the set call?
As this is a deny by default interface which only allows you to further restrict you couldn't add more than 1 syscall if you didn't have an explict 'apply' action.
SECCOMP_FILTER_SET, __NR_fo, "a=0" SECCOMP_FILTER_SET, __NR_read, "1" == EPERM
Maybe apply on set is fine after the first apply, but we definitely need some way to do more than 1 set before the rules are applied....
-Eric
| ![\](/images/icornerr.gif) |