Quoting Tony Jones (tonyj@private): > On Fri, Aug 26, 2005 at 08:29:58AM -0400, Stephen Smalley wrote: > > On Fri, 2005-08-26 at 07:58 -0400, Stephen Smalley wrote: > > > Ok, as with my prior comment, this one is also invalidated by the fact > > > that the static inlines fall back to the cap_ functions if the operation > > > is NULL. So I suppose this would work. > > > > Given these changes, what purpose does the capability module and the > > CONFIG_SECURITY_CAPABILITIES option serve anymore? Should capability.c > > be removed entirely? > > Since stacker will implement every hook (preventing the static inline > falling thru) wouldn't retaining capability as a module for composition > be useful? For conceptual simplicity I think keeping an actual module for it around will be best. Then other module can either stack with it, or not, however they prefer. > Of course I can see alternate methods for implementing this. At the very least, > as this thread demonstrates, the current stacker approach of calling dummy > when no submodule implements a hook will need some rework. Actually that's not quite the way it works under stacker right now. If no module is loaded, then dummy is used, but if a module is loaded, then stacker doesn't call dummy__hook if the module doesn't define that hook. (Though there are a few hooks which are specially handled, ie __vm_enough) So switching from having dummy be the default module when nothing is stacked, to having capability, is simple enough. -serge
This archive was generated by hypermail 2.1.3 : Fri Aug 26 2005 - 09:51:14 PDT