Subject: Re: bin/14172
To: Emmanuel Dreyfus <manu@netbsd.org>
From: David Laight <david@l8s.co.uk>
List: tech-userlevel
Date: 12/05/2002 08:54:32
> - kern_prot.c:setgroups(), uses it to set the size of a local variable.
> It would be easy to do a malloc instead.
You also need to look at the emulation versions ehere the user
passes in 16bit group ids.
In any case it isn't hard...
> - portal and nfs code just use it to bound loops and do sanity checks,
> so the change to a global variable would easy here.
>
> - Three data structure use it: struct portal_cred, struct ucred and
> struct uucred. If the value becomes dynamic, we need to implement the
> array as a chained list. I wonder how much it impacts performance and
> memory usage. Another solution would be to malloc the struct ucred, and
> on NGROUP change realloc all struct ucred, but I'm not sure it feasible.
That was what I had intended, at least for struct ucred.
Add 'ngroups' parameter to crget(), crcopy() and crdup() and follow
the consequences.
> We can walk through struct ucred used by strut proc, but there are other
> places struct ucred are used: struct file, and struct netexport
> (possible interoperability problem here: does mountd expects a fixed
> amount of 16 secondary groups?).
I didn't quite sort out what mountd was up to (IIRC it allocates an
on-stack struct ucred somewhere, it also was one embedded in another
structure (it doesn't get to user space).
I think the NFS wire protocol is limited to 16 groups (sometimes 8).
> - struct uucred is the userland view of struct ucred, and it should not
> change, but we just fill it from struct ucred and return it to userland,
> so we can build an array from a chained list, that's not a problem.
It also isn't used often... Think only the mountd stuff.
>
> Therefore except if someone has a bright idea for the credential
> storage, yes, it would be messy.
Mountd is lively - because you have to work out what it is doing,
the rest is trivial.
David
--
David Laight: david@l8s.co.uk