* Casey Schaufler (caseyat_private) wrote: > David Wagner wrote: > > > Well, this seems like an awfully contrived example. > > The cluster file system manager, the near-line > storage manager, and the security manager all > looked at the customer bug report and said pretty > much the same thing. Then they spent a couple days > figuring out how to fix it. Am I missing something here? The MAC check and the DAC check are too late for this conversation to take on any meaning. The inode is used for both. The inode contains the mode bits used in the DAC check. The inode is either: 1) cached...no performace issue with slow tape. 2) not cached...go look it up on that slow tape. If we are dealing with case 2, the ordering of the MAC and DAC checks are absolutely meaningless with repsect to performance. The determining factor will be neither the MAC nor the DAC check, but the path name -> inode resolution time. The only way you could elleviate this, is if you make the check based on absolute pathname. And even here, if you spin your own mechanism to determine the absolute pathname you are out of sync with the kernel, and if you use the dentry the kernel gave you from its lookup you just hit the tape (unless all parts of the path are already cached). Again, I may be mis-interpreting, so I trust you'll correct my mal assumptions ;-) 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 : Fri Jul 27 2001 - 10:25:04 PDT