Thread (77 messages) 77 messages, 12 authors, 2011-05-29

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

From: Ingo Molnar <hidden>
Date: 2011-05-13 12:54:52
Also in: linux-arm-kernel, linuxppc-dev

* Peter Zijlstra [off-list ref] wrote:
On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote:
quoted
quoted
      event_vfs_getname(result);
      result = check_event_vfs_getname(result); 
Another fundamental difference is how to treat the callback chains for
these two.

Observers won't have a return value and are assumed to never fail,
therefore we can always call every entry on the callback list.

Active things otoh do have a return value, and thus we need to have
semantics that define what to do with that during callback iteration,
when to continue and when to break. Thus for active elements its
impossible to guarantee all entries will indeed be called.
I think the sanest semantics is to run all active callbacks as well.

For example if this is used for three stacked security policies - as if 3 LSM 
modules were stacked at once. We'd call all three, and we'd determine that at 
least one failed - and we'd return a failure.

Even if the first one failed already we'd still want to trigger *all* the 
failures, because security policies like to know when they have triggered a 
failure (regardless of other active policies) and want to see that failure 
event (if they are logging such events).

So to me this looks pretty similar to observer callbacks as well, it's the 
natural extension to an observer callback chain.

Observer callbacks are simply constant functions (to the caller), those which 
never return failure and which never modify any of the parameters.

It's as if you argued that there should be separate syscalls/facilities for 
handling readonly files versus handling read/write files.

Thanks,

	Ingo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help