On Fri, 2005-11-25 at 16:45 +0800, Hawk Xu wrote: > I really think that we should have an inode_post_removexattr, otherwise > we have no method to update the in-core i_security after removing xattr > of an inode, assume that the infomation pointed by i_security is related > to the xattr. > > There are two solutions: > > 1. We could move inode_post_setxattr hook call to a deeper place where > both setxattr and removexattr syscalls will reach, e.g. in both > generic_setxattr() and generic_removexattr(), just before > `handler->set(...)'. But this is not recommended because > inode->i_op->setxattr may not point to generic_setxattr, and > inode->i_op->removexattr may not point to generic_removexattr. > > 2. Add an inode_post_removexattr hook to the LSM framework. The hook is > called by removexattr() function in fs/xattr.c, after successful > removexattr operation. See the patch in the attachment. The patch is > against 2.6.14.3. > > > Any idea? We didn't include such a post hook originally because SELinux simply prohibits removal of the selinux attributes entirely (you can change them to another value subject to policy, but never remove them altogether while SELinux is enabled). That is conventional for a MAC implementation - an object should always be labeled in some manner. In your case, if you need such a post hook, I'd favor the latter approach, but note that you likely want to do this while the semaphore is still held, as with post_setxattr, so that the entire sequence (permission check, xattr state update, and incore security update) is atomic with respect to any other setxattr or removexattr calls. Note also that you can't simply clear and free what is referenced by the i_security field in your post hook, as it can still be accessed by other threads; that has to be deferred until inode_free_security. You also need to re-base your patch to the latest available (e.g. 2.6.15-rc2-mm1) for upstreaming, particularly since the xattr code has been re-factored in -mm by hch. And of course, to motivate your hook, you need to provide a URL to a copy of your LSM, to show why it is needed and how it is used, unless it is just viewed as an obvious gap in the current hook set (arguable either way). -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Mon Nov 28 2005 - 08:03:58 PST