From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 27 11:17:27 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 E6C0416A496 for ; Thu, 27 Sep 2007 11:17:27 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 85CE613C50C for ; Thu, 27 Sep 2007 11:17:27 +0000 (UTC) (envelope-from gahr@gahr.ch) Received: from town.bfh.ch ([147.87.98.171]) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IarMx-0000Q9-SZ; Thu, 27 Sep 2007 13:17:23 +0200 Message-ID: <46FB913B.7070409@gahr.ch> Date: Thu, 27 Sep 2007 13:17:15 +0200 From: Pietro Cerutti User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070925093722.N21960@mail.rsync.net> <20070927110900.GD1193@garage.freebsd.pl> In-Reply-To: <20070927110900.GD1193@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gahr.ch X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, "rsync.net" 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 11:17:28 -0000 Pawel Jakub Dawidek wrote: > On Tue, Sep 25, 2007 at 09:51:06AM -0700, rsync.net wrote: >> It has been impossible to change kern.ngroups - at least for several years >> now. It was not fixed in either 5.x or 6.x : >> >> http://lists.freebsd.org/pipermail/freebsd-bugs/2007-January/022140.html >> >> It is seemingly a difficult problem: >> >> http://www.atm.tut.fi/list-archive/freebsd-stable/msg09969.html [1] >> >> However it should be solved - we can't be the only ones out there trying >> to add a UID to more than 16 groups... >> >> >> ----- >> >> >> The rsync.net code bounties have been fairly successful this year - two of >> the five projects have been completed, and the large "vmware 6 on FreeBSD" >> project is now underway. >> >> We'd like to add a new bounty for this kern.ngroups issue. We are posting >> to -hackers today to get some feedback on how long this will take and how >> much money might reasonably be expected to lure this work. >> >> >> --rsync.net Support >> >> >> >> [1] Is it indeed true that these programs are broken by not following >> NGROUPS_MAX from syslimits.h? > > I don't see how they can be broken. They may not see more than 16 > groups, but they shouldn't blow up. The only possibility of bad usage I > see is something like this: > > gid_t gids[NGROUPS_MAX]; > int gidsetlen; > > gidsetlen = getgroups(0, NULL); > getgroups(gidsetlen, gids); > > But I guess the most common use is: > > gid_t gids[NGROUPS_MAX]; > int gidsetlen; > > gidsetlen = getgroups(NGROUPS_MAX, gids); > > Binaries using the latter method should be just fine. > BTW. The latter method is what all utilities from the base system use. > Anyway, why should we worry about possible breakage software written with a bad design? -- Pietro Cerutti PGP Public Key: http://gahr.ch/pgp