On Tue, 5 Jun 2001 jmjonesat_private wrote: > I don't see how NOT having two sets of hooks is possible, here, without > closely examinining each and every possible implementation of each and > every hook.... past, present, and future. I'm not sure what you mean. Consider fs/namei.c:permission. Suppose that we decide that we would like to make the permission() hook authoritative (i.e. it can grant what would be denied by DAC or it can deny what would be granted by DAC) rather than merely restrictive. So we add a parameter to the permission() hook that expresses the kernel decision, and change the permission function to the following: int permission(struct inode * inode, int mask) { int retval; if (inode->i_op && inode->i_op->permission) { lock_kernel(); retval = inode->i_op->permission(inode, mask); unlock_kernel(); } else { retval = vfs_permission(inode, mask); } return security_ops->inode_ops->permission(inode, mask, retval); } Now the permission hook function is authoritative - it can be restrictive or permissive. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 Jun 05 2001 - 12:51:28 PDT