Re: Locking task->security

offerat_private

* frm gregat_private "08/30/01 15:39:29 -0700" | sed '1,$s/^/* /'
*
* On Thu, Aug 30, 2001 at 02:47:22PM -0700, richard offer wrote:
*> 
*> \begin{A non-kernel person stupid question}
*> 
*> I have my own blob in current->security, it comprises a bunch of data
*> that I think I need to lock access to.
*> 
*> My naive options appear to be :-
*> 
*>     1) lock the whole task structure (very bad)
*>     2) add a new security specific lock to the task to protect access to
*> the security blob
*>     3) add a lock inside the structure hanging off security (bad)
*>     4) add a global policy specific lock (bad)
* 
* Do either #1 or #3, but do it _within_ your module.  Since the
* ->security blob is only being touched by your module, only you know what
* kind of lock you need, and when you need it.  So hang it off of the
* security blob, or have a static lock in your module that you use.

Wouldn't a static lock be 4) (that was what I meant by 4)) ?

* 
* Remember, there are a lot of different kinds of locks, all for different
* things, picking any one of them as the "security" lock in the LSM code
* would not work for everyone.

See...if only there was only one lock it would be easy :-) Having a void *
security_lock member in the task struct would provide enough mechanism for
2) without setting policy.

* 
* Does that help?

From Chris's explanation it seems that I shouldn't need to lock
current->security only the contents of current->security is that true ?
Assuming the worst case scenario, is there no way that current->security
(not the contents) can be accessed from multiple locations simmultaniously
? Is it possible for a single process to call two system calls at the same
time ? My guess is no, not with the current threading model (n-to-1) ?

Are there any plans to re-do the threading to provide a n-to-m type model ?
Wouldn't that sort of be something needed to get Linux to scale to higher
CPU counts (in terms of usefulness to applications) ? 

* 
* thanks,
* 
* greg k-h

richard.

-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module