* Stephen Smalley (sdsat_private) wrote: > > On Mon, 17 Sep 2001, Chris Wright wrote: > > > + * Check permission before accessing an inode. This hook is > > + * called when an inode is opened, is a directory element in a > > + * pathname or is a parent directory for inode creation/deletion, > > + * whereas the file_security_ops hooks are used to mediate access > > * when the actual read/write operations are performed. > > * Return 0 if permission is granted. > > */ > > Although this description does capture more of the uses of this hook, > there are certainly other uses as well, such as checking execute access > for execve(), checking write access for truncate() and utimes(), checking > the requested access for access(), checking write access for Unix domain > socket connect()/sendmsg(), etc. The permission() function is used fairly > pervasively, so it seems difficult to capture all of its uses. The > important thing is to clearly differentiate the file_security_ops > permission hook from the inode_security_ops permission hook. I agree that our fundamental need is to differentiate the use of the file_security_ops and inode_security_ops permission functions. I didn't think listing all uses would be useful, just confusing. In general the inode_ops check is an inode attribute check, whereas the file_ops is the check against the way the file was opened. Perhaps something as succinct as that would suffice. thoughts? -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 Sep 18 2001 - 09:43:40 PDT