Quoting Stephen Smalley (sds@private): > 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. I hadn't considered that. It does seem to then enforce that any security module keeping state on kernel objects must be compiled in so as to catch them when they are created. But that may not be a bad thing, and it would be nice to be able to drop the rwlock. thanks, -serge
This archive was generated by hypermail 2.1.3 : Tue Feb 01 2005 - 05:16:45 PST