On Sun, 2007-04-08 at 13:08 +0800, Hao Xu wrote: > Hi! > > If the purpose of the LSM framework is not just satisfying selinux, then > the reason for adding this hook is obvious: we NEED a way to update the > incore inode security data after successful removexattr operations, it's > undoubtedly necessary for a xattr based security module. I don't > consider the framework as complete without this hook. > > I didn't give the patch here because it's trivial. I'd like to hear some > comments first.
I don't recall people arguing against such a hook per se, just against freeing and clearing i_security in it (as that should happen upon inode_free_security). Feel free to submit a patch for it. Only caveat I would raise is that you want to be careful about atomicity/locking there. In the setxattr case, the inode mutex is held across the entire sequence (security_inode_setxattr();inode->i_op->setxattr();security_inode_post_setxattr();) as a way of ensuring that setxattr calls by different tasks/threads on the same inode don't lead to an inconsistency - that kind of guarantee has to be supported by the vfs; it can't be provided solely within your security module. You also have to worry about an interleaving where the i_security field may be used by another thread while you are performing your post_removexattr handling - that kind of guarantee can be handled internally within your hook functions (trivially if you are only updating and accessing a single word value, like isec->sid). -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
