> - 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