Quoting serue@private (serue@private): > Quoting Tony Jones (tonyj@private): > > Hi Serge, > > > > I have a question about stacker_vm_enough_memory. > > > > I note that SELinux doesn't implement the vm_enough_memory hook right now, so > > fixup_ops gives them dummy_vm_enough_memory. Same for our module currently > > in an unstacked setup. > > > > For stacker, if no module is registered, stacker_vm_enough_memory calls > > capable() rather than dummy_capable() [but the problem would be the same > > if capability was the first module in the list (or any module who's > > vm_enough_memory hook called capable().] > > > > The issue is that if any module in the chain tries to do any auditing based > > on rejecting capable() things get quite noisy. > > Another good catch. Stacker should not be using capable, but IMO that > is because it should not be setting PF_SUPERPRIV if the request was > granted. So I believe stacker should loop through each stacked > module's capable() function for an answer. > > But that would still call your module's capable(). I take it that is > not sufficient? What would you suggest? Always using > default_module->capable()? The attached patch causes stacker to call each stacked module's capable() instead of calling top-level capable to determine the cap_sys_admin argument to __vm_enough_memory() when no stacked modules have defined their vm_enough_memory hooks. Again, I'm not sure this actually addresses your concern - it sounds to me like you don't want your own module to get a capable(CAP_SYS_ADMIN) for vm_enough_memory(). If that is the case, I believe the best thing to do is to have your module define vm_enough_memory() so that the stacker code calling capable isn't used. Or, assuming you stack with capability or cap_stack, then that module will define it for you. As Stephen pointed out, that is how SELinux avoids this problem. thanks, -serge
This archive was generated by hypermail 2.1.3 : Wed Jun 29 2005 - 09:08:43 PDT