On Thu, 30 Aug 2001, richard offer wrote: > I think I need to protect access to current->security as well as the > contents of current->security. > > If I've got two threads that both think current->security is NULL and both > try to create a new one, I think I'm going to have problems. This is unlikely to be a problem with current->security. A better example is inode->i_security or sb->s_security, where you are more likely to have a race on the allocation of the security object. Of course, this only happens if the precondition function catches an object without a security blob and performs the allocation. If the ordinary alloc_security hook is used, then the kernel object has just been allocated and is not accessible yet to other tasks. So if you build your module into the kernel, then this should not be an issue. If you dynamically load your module into a running kernel, then this could easily happen. Notice that we test for a race condition on the setting of inode->i_security in the inode_alloc_security function in the SELinux module, but we don't really have a good way of handling the situation. It hasn't been a priority for us, since we are advising our users to always build the module into the kernel. -- 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 : Fri Aug 31 2001 - 05:21:53 PDT