Quoting tvrtko.ursulin@private (tvrtko.ursulin@private): > >stacker.patch: Main change is that, since mod_reg_security() > >actually calls verify(ops), all ops->hooks which were > >not defined will be pointing to the dummy hooks, so > >there is no reason to check > >if (m) > >m->hook(); > >so stacker now just calls m->hook(). This might provide > >some performance improvement, particularly if the > >m->hook call was on the path requiring the jump. (I > >haven't checked that). > > Doesn't this break restrictive stacked hooks? For example you have two > modules stacked, capabilites.ko and a 3rd party one. Stacker ask > capability on capset_check and gets 0. Then it asks 3rd party for it, > which doesn't care, but dummy gets called and says -EPERM. The end result > is -EPERM which is not what we want. > > Had been bitten by it and have a set_to_null_if_dummy in my stacker > register_security. :) Compared to the last stacker patch, there should be no change in behavior, only in performance. But I think you're saying the same thing Stephen is saying: we should reconsider the calling of verify(ops) on a mod_reg_security call. That sounds good to me. Does anyone disagree? thanks, -serge
This archive was generated by hypermail 2.1.3 : Tue Feb 01 2005 - 05:20:24 PST