On Thu, Nov 24, 2005 at 06:43:34PM +0800, Hawk Xu wrote: > >Most of the security labels on kernel objects have distinct alloc/free > >hooks for a reason. In the freeing case the kernel usually calls the hook > >when usage falls to zero and the kernel object is about to be released. > >Attempting to zero *_security outside of this situation is asking for > >problems unless you absolutely know what you're doing (locking wise) and > >even then I wouldn't recommend it. > I mean, after removing the xattr of an inode(on the disk), how do I > update(set to zero, or release it) the i_security field of the Short answer, you don't. Long answer, see above :-) > inode(in-core)? If the in-core inode security attributes is not updated > after sys_removexattr(), it is still under control of the xattr security > attributes, which is not desired(at least by my MAC LSM). Sure but this has little or nothing to do with zeroing i_security. It sounds like you have need to reflect a change of state into your object and there is no current hook. You've proposed a new one. If this change of state results in you needing to completely ignore i_security (as if it were NULL) then you need to manage this internally inside your code/object (with of course the necessary internal locking if required). So you are 'logically' invalidating i_security without actually physically doing so. It is physically deallocated when the inode kernel object is destroyed. Hopefully this makes sense. Tony
This archive was generated by hypermail 2.1.3 : Mon Nov 28 2005 - 15:03:17 PST