* Stephen Smalley (sdsat_private) wrote: > > In addition to avoiding sleeping operations, the security module has to > ensure that it does not call a locking dcache operation, e.g. d_find_alias > or d_path, during any hook called from this function. This might be an > issue for some modules that try to audit a pathname, forcing them to > return -EAGAIN if they need to call the dcache. Yes, thanks, sorry for being vague about dcache lock issues. > The second option seems to invalidate the whole point of the dcache > fastwalk changes, only retaining the optimization when the Linux DAC > logic would deny access. I'd vote for the first option. Indeed. Just threw it out as something to ponder, really just an attempt to avoid adding new hooks ;-) There is still the issue that the capable() hook can sleep. We can't distinguish these capable() calls, and in SELinux, for example, capable() could call task_alloc_security() which could sleep (unless I'm misreading the code). Placing the proposed permission_lite() hook ahead of the DAC checks could fix this, but it would be out of sync with the rest of the LSM hooks where placement is intended to be after DAC checks. cheers, -chris _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Tue May 07 2002 - 10:05:28 PDT