> > > We could introduce a runtime sysctl-able limit, say 256, for instance,
> > > and return that value?
> 
> this actually seems to be what we (netbsd) would prefer, 
> after reading the sysconf man page.

If you read the posix version, you find that -1 can either
mean 'error', or 'unlimited' (ie not restricted in this manner!).

> > Having reread the posix/opengroup spec, it looks as though the
> > 'correct' thing is to #define NGROUPS_MAX to (say) 16 and have
> > sysconf(_SC_NGROUPS_MAX) return -1.
> 
> theorhetically this is doable now, it just has to be 
> implemented.

I would do it....
I see no reason to enforce a limit - if you allow it to be 'large'
the code has to treat it as infinite.  If the limit were, say, 256
then someone who added a 257th group would only have to remember
to up the limit.  Since only root can do anything that sets
this up it doesn't really matter.
(actually a limit might be set - but one which is large enough that
reporting -1 would be correct anyway)

> So, after further review, it looks like the PR has
> morphed into 2 issues really:
> 
> 1) bad error reporting
> 
> 2) using sysconf for posix compliance

3) bad coding - the libutil routine that does getgrouplist/intgroups
   (forgotten its name) doesn't obey its man page and passes invalid
   data to the kernel.

4) enhancing the kernel to support indefinite numbers of groups

> recall our statement of "posix within reason".

Yes - keeps the code porting punters happy.

	David

-- 
David Laight: david@l8s.co.uk