Re: quotactl hook

jmjonesat_private

On Sun, 2 Sep 2001, Greg KH wrote:

> On Sat, Sep 01, 2001 at 08:48:23PM -0400, jmjonesat_private wrote:
> > 
> > How?
> > 
> > If the "blob" is not allocated and the module gets it, how do I lock it
> > prior to one of the threads allocating and starting it flying?
> 
> Here's one way to do it:
> 
> This is all in your module code:
> 
> static struct semaphore task_semaphore;
> 
> int my_module_init_function (void)
> {
> 	init_MUTEX (&task_semaphore);
> 
> 	/* now register my module with the lsm framework */
> 	...
> }
> 
> int my_module_task_alloc_security (struct task_struct *p)
> {
> 	down (&task_semaphore);
> 	if (p->security == NULL) {
> 		p->security = kmalloc (sizeof (struct my_task_security_struct));
> 		if (p->security == NULL) {
> 			up (&task_semaphore);
> 			return -ENOMEM;
> 		}
> 		init_MUTEX (&p->security->semaphore);
> 		/* init the rest of your stuff */
> 		...
> 	}
> 	up (&task_semaphore);
> 	return 0;
> }
> 
> int my_module_task_setgroups (int gidsetsize, gid_t *grouplist)
> {
> 	if (current->security == NULL) {
> 		ret = my_module_task_alloc_security (current);
> 		if (ret)
> 			return ret;
> 	}
> 	
> 	down (&current->security->semaphore);
> 	/* do my stuff that changes the contents of current->security */
> 	...
> 	up (&current->security->semaphore);
> 
> 	return 0;
> }
> 
> 
> So you have a semaphore that protects you initializing the task
> structure's security blob.  This has to be a semaphore as you will be
> calling kmalloc which can sleep (can't hold a spinlock across a sleep).
> 
> And you check the value of p->security _after_ you get the lock in case
> you were sleeping on the lock when another call was allocating the same
> structure.
> 
> Then you have a local semaphore (or can be a spinlock, just don't call
> any sleepable functions while it is held.  these are functions like
> kmalloc, copy_*_user, printk, and others) that protects your local data
> within your blob.  A read_write lock might be good to use for your
> internal data if you find that you are mostly reading things and not
> writing them.  Check out the research done in the netfilter locks if you
> want to see some truly looney read_write locks that are very cool (paper
> was presented at OLS 2001 about this.)
> 
> Did that help?  Much easier than keeping a list of places you've been.
> 

Actually, YES, greatly.

I have a belief, perhaps ignorant, that this list will produce a patch in
the kernel that becomes part of the 2.5 or 2.6 and provides significant
value to Linux.

That includes the patch, and the implied value from the project that "got
it in."  I haven't evaluated this code, yet, but the fact of your
contribution of it to the commonality allows me to do so, and to "spin"
discussions outward from there.

> Usual disclaimer applies, this is not tested code, was written first
> thing in the morning before really waking up, etc...

Any concern or body that incorporates code without evaluation deserves
what they get.... this is a good argument.  Let's discuss the
implications?

> 
> greg k-h
> 

J. Melvin Jones

|>------------------------------------------------------
||  J. MELVIN JONES            jmjonesat_private 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

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