kern.ngroups (non) setting ... new bounty ?

[John Baldwin]

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