On Tue, 2005-02-01 at 06:49, Stephen Smalley wrote: > On this topic, if security_set_value* is only called from hooks like > alloc_security where the kernel object is not yet accessible to other > threads and if security_del_value* is only called from hooks like > free_security where the last reference to the object has already been > released, then why do you need locking in the security_[gs]et_value > functions at all? The chains are per-object, and are only modified when > the object is not accessible to other threads. This appears to be valid > for usage by SELinux. Or am I missing something? Ok, I looked at your patch for seclvl as well, and I see that you are calling security_set_value_type indirectly from the inode_permission hook there, then freeing any old value to avoid a leak due to a race? Still seems a bit questionable; life will be much simpler if we just insist that the chains are only modified from the alloc_security/free_security hooks. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Tue Feb 01 2005 - 04:33:08 PST