Messages in this thread |  | | | Subject | Re: [PATCH 5/7] seccomp_filter: Document what seccomp_filter is and how it works. | | From | Eric Paris <> | | Date | Fri, 06 May 2011 09:35:37 -0400 |
| |
On Fri, 2011-05-06 at 07:53 -0400, Steven Rostedt wrote: > On Thu, 2011-05-05 at 02:21 -0700, Will Drewry wrote: > > > In particular, if the userspace code wants to stage some filters and > > apply them all at once, when ready, I'm not sure that it makes sense > > to me to put that complexity in the kernel itself. For instance, > > Eric's second sample showed a call that took an array of ints and > > coalesced them into "fd == %d || ...". That simple example shows that > > we could easily get by with a pretty minimal kernel-supported > > interface as long as the richer behavior could live userspace side -- > > even if just in a simple helper library. It'd be pretty easy to > > implement a userspace library that exposed add_filter(syscall_nr, > > filter) and apply_filters() such that it could manage building the > > final filter string for a given syscall and pushing it to prctl on > > apply. > > I'm fine with a single kernel call and the "temporary filter" be done in > userspace. Making the kernel code less complex is better :)
I'm also starting to think a userspace library is a good idea as well. Everything in the kernel is an && with nothing but SET and APPLY. We provide interfaces to build the strings as we go along including UNSET and stuff like that if there are users.... -Eric
|  |