Tony Jones wrote: >I can only suggest reading include/linux/security.h. > >Assign module specific data to i_security in your 'inode_alloc_security' hook. >Release it in your 'inode_free_security' hook. > >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. > >Tony > 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 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). Thanks! -- Best regards, Hawk Xu, M.S.C.S. h.xu `echo "ta"|rev` 163 `echo "tod"|rev` com
This archive was generated by hypermail 2.1.3 : Thu Nov 24 2005 - 03:00:13 PST