From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 27 13:38:04 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB8B516A417; Thu, 27 Sep 2007 13:38:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CFE8713C44B; Thu, 27 Sep 2007 13:38:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 7FFFE1A4D94; Thu, 27 Sep 2007 06:38:03 -0700 (PDT) From: John Baldwin To: freebsd-hackers@freebsd.org, Harti Brandt Date: Thu, 27 Sep 2007 09:26:31 -0400 User-Agent: KMail/1.9.7 References: <20070925093722.N21960@mail.rsync.net> <46FB913B.7070409@gahr.ch> <20070927133713.R63884@knop-beagle.kn.op.dlr.de> In-Reply-To: <20070927133713.R63884@knop-beagle.kn.op.dlr.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709270926.31739.jhb@freebsd.org> Cc: Pawel Jakub Dawidek , "rsync.net" , Pietro Cerutti Subject: Re: kern.ngroups (non) setting ... new bounty ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2007 13:38:05 -0000 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