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 should worry about all software in the base system. Especially if the implications are security related. BTW - the software is not necessary bad designed - it may just be old. There are things to think about: in several places the group list would be truncated: NFS, struct ucred, struct xucred, struct kinfo_proc, struct cmsgcred (this is just from a grep in include/sys). Truncating is ok as long as you use group membership only to give access to a ressource - the user will just not be able to access a ressource that in principle he should be able to access. Unfortunately someone in the past thought that making negative decisions based on group membership would be a nice thing (prominent example: NTFS). Here truncating the group list has the effect of giving access to resource the user should have no access to. I don't think the brain-dead concept of deny groups is used anywhere in the base system, but applications certainly could use it and in this case surprises are just waiting to pop up by ignoring the truncation problem. harti _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
