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