> .. is there really a demand for an 'unlimited' NGROUPS_MAX?  With the
> present data structure, even a run-time changeable limit could be
> messy to implement.

A quick grep in kernel sources shows the following uses for NGROUPS and
NGROUPS_MAX:

- compatibility modules that emulate sysconf or sysctl just return its
value. No problem to change this except testing.

- kern_prot.c:setgroups(), uses it to set the size of a local variable.
It would be easy to do a malloc instead.

- 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.
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?). And there would be locking problems,
this is a nightmare.

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

Therefore except if someone has a bright idea for the credential
storage, yes, it would be messy.
 
-- 
Emmanuel Dreyfus.
NetBSD, parceque je le vaux bien.
manu@netbsd.org