Re: LSM stacker update

From: Stephen Smalley (sds@private)
Date: Tue Feb 01 2005 - 03:49:27 PST


On Mon, 2005-01-31 at 15:33, Stephen Smalley wrote:
> This would also mean that the performance and scalability overhead of
> stacker has to be minimal, as it would effectively become a dependency
> for normal use of SELinux.  That may require revisiting the locking
> scheme for the chained security objects.

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?

-- 
Stephen Smalley <sds@private>
National Security Agency



This archive was generated by hypermail 2.1.3 : Tue Feb 01 2005 - 03:56:27 PST