In considering the whole question of making the permission hook authoritative (whether by passing the kernel decision to it or by moving the kernel logic into the module), it occurred to me that the setattr hook in notify_change poses a more difficult problem. If the file system does not implement its own inode setattr routine, then notify_change separates the access checking (the call to inode_change_ok) from setting the attributes (the call to inode_setattr). So we could easily pass the result of the inode_change_ok logic or move that logic into the setattr hook, allowing the setattr hook to be authoritative in this case. But if the file system defines its own inode setattr routine, then there is no separation at this level - the inode setattr routine is expected to both check access and set the attributes. Furthermore, in some cases, like remote file systems, the actual access checking may not be performed at all on the local system - it may be handled entirely by the server. So in this situation the setattr hook can only be restrictive. -- 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 : Thu Jun 07 2001 - 08:32:31 PDT