* richard offer (offerat_private) wrote: > > > * frm chrisat_private "08/30/2001 03:10:12 PM -0700" | sed '1,$s/^/* /' > * > ** richard offer (offerat_private) 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) > *> > *> 2 seems to be the most obvious one to me, but that raises the question > *> why it doesn't seem to have been mentioned before, what am I missing ? > * > * why do you say 3) is bad? for example the mm_struct that hangs off > * the task_struct has a lock in it. > > Right, but the lock only protects some members of the mm_struct (mm->rss), > not the struct itself, that is protected by alloc_lock ? > > 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. if you have two threads allocating a security blob for the same task_struct i think you do have problems. each thread should have its own task_struct, and the clone call should be allocating the security blob for each task_struct. if you are worried about multiple allocations then lock the task_struct for the allocations, and use your own locking mechanism to protect the security blob contents when mucking with the contents. my $0.02 worth, -chris _______________________________________________ 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 : Thu Aug 30 2001 - 17:02:39 PDT