Date: Thu, 27 Sep 2007 09:26:31 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org, Harti Brandt <harti@freebsd.org> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, "rsync.net" <info@rsync.net>, Pietro Cerutti <gahr@gahr.ch> Subject: Re: kern.ngroups (non) setting ... new bounty ? Message-ID: <200709270926.31739.jhb@freebsd.org> In-Reply-To: <20070927133713.R63884@knop-beagle.kn.op.dlr.de> References: <20070925093722.N21960@mail.rsync.net> <46FB913B.7070409@gahr.ch> <20070927133713.R63884@knop-beagle.kn.op.dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 27 September 2007 07:48:02 am Harti Brandt wrote: > 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. And some sysadmins may use it via 'chmod 606' or the like. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709270926.31739.jhb>