From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 27 12:01:17 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 8A68716A419; Thu, 27 Sep 2007 12:01:17 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id 2D37913C474; Thu, 27 Sep 2007 12:01:16 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 13:47:58 +0200 Date: Thu, 27 Sep 2007 13:48:02 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Pietro Cerutti In-Reply-To: <46FB913B.7070409@gahr.ch> Message-ID: <20070927133713.R63884@knop-beagle.kn.op.dlr.de> References: <20070925093722.N21960@mail.rsync.net> <20070927110900.GD1193@garage.freebsd.pl> <46FB913B.7070409@gahr.ch> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 27 Sep 2007 11:47:59.0009 (UTC) FILETIME=[40452110:01C800FC] Cc: freebsd-hackers@freebsd.org, Pawel Jakub Dawidek , "rsync.net" Subject: Re: kern.ngroups (non) setting ... new bounty ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt 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 12:01:17 -0000 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