kern.ngroups (non) setting ... new bounty ?

[Pietro Cerutti]

Pawel Jakub Dawidek wrote:
> On Tue, Sep 25, 2007 at 09:51:06AM -0700, rsync.net wrote:
>> It has been impossible to change kern.ngroups - at least for several years
>> now.  It was not fixed in either 5.x or 6.x :
>>
>> http://lists.freebsd.org/pipermail/freebsd-bugs/2007-January/022140.html
>>
>> It is seemingly a difficult problem:
>>
>> http://www.atm.tut.fi/list-archive/freebsd-stable/msg09969.html   [1]
>>
>> However it should be solved - we can't be the only ones out there trying
>> to add a UID to more than 16 groups...
>>
>>
>> -----
>>
>>
>> The rsync.net code bounties have been fairly successful this year - two of
>> the five projects have been completed, and the large "vmware 6 on FreeBSD"
>> project is now underway.
>>
>> We'd like to add a new bounty for this kern.ngroups issue.  We are posting
>> to -hackers today to get some feedback on how long this will take and how
>> much money might reasonably be expected to lure this work.
>>
>>
>> --rsync.net Support
>>
>>
>>
>> [1]  Is it indeed true that these programs are broken by not following
>>      NGROUPS_MAX from syslimits.h?
> 
> I don't see how they can be broken. They may not see more than 16
> groups, but they shouldn't blow up. The only possibility of bad usage I
> see is something like this:
> 
> 	gid_t gids[NGROUPS_MAX];
> 	int gidsetlen;
> 
> 	gidsetlen = getgroups(0, NULL);
> 	getgroups(gidsetlen, gids);
> 
> But I guess the most common use is:
> 
> 	gid_t gids[NGROUPS_MAX];
> 	int gidsetlen;
> 
> 	gidsetlen = getgroups(NGROUPS_MAX, gids);
> 
> Binaries using the latter method should be just fine.
> BTW. The latter method is what all utilities from the base system use.
> 

Anyway, why should we worry about possible breakage software written
with a bad design?

-- 
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp