On Fri, 2008-10-24 at 13:28 -0400, Eric Paris wrote: > On Fri, 2008-10-24 at 11:08 -0400, Stephen Smalley wrote: > > On Fri, 2008-10-24 at 11:05 -0400, Eric Paris wrote: > > > > Do others have thoughts? > > > > Seems similar to the vm_enough_memory() case, where we likewise > > introduced a separate security hook that internally checks without > > auditing. > > > > The OOM killer likewise ought to be using a non-auditing form of > > capability checks. > > So would you suggest a generic non-auditing capability checking > mechanism or a specific hook for "things to use" > > * capable_noaudit(current, cap) > * security_capable_noaudit(current, cap) > * security_cap_sys_resource(current) > > Looks like oom also checks CAP_SYS_ADMIN so maybe a generic cap > interface would be best. In the vm_enough_memory() case, I think it was Alan Cox's idea to take the entire policy logic into a distinct security hook so that you could ultimately support policy-based resource constraints. Versus only introducing a non-auditing variant of the capable check. If we wanted to be consistent, we'd likewise introduce distinct hooks for these cases and take more of the logic into them, not just the capability check. I'm open to either approach though. > esandeen: I still think it would be a good idea to simplify > ext4_claim_free_blocks() and ext4_has_free_blocks() which seems to have > a lot of code duplication and both have the unconditional capable > calls... -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
