From owner-freebsd-hackers Thu Dec 26 19:01:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA26491 for hackers-outgoing; Thu, 26 Dec 1996 19:01:43 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA26486 for ; Thu, 26 Dec 1996 19:01:37 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.4/8.6.9) id OAA01377; Fri, 27 Dec 1996 14:00:01 +1100 (EST) Message-ID: Date: Fri, 27 Dec 1996 14:00:01 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: owensc@enc.edu (Charles Owens) Cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-hackers@freebsd.org (FreeBSD hackers), ben@narcissus.ml.org Subject: Re: multi-group file access techniques / directory hardlinks References: <199612262141.WAA00148@uriah.heep.sax.de> X-Mailer: Mutt 0.54 Mime-Version: 1.0 In-Reply-To: ; from Charles Owens on Dec 26, 1996 19:30:43 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Charles Owens writes: > > It's probably better to concentrate on a one group per user technique, > > and put all the other people who are allowed mutually into secondary > > groups. The ugly old limits for secondary groups have just been > > killed (but this won't be in 2.2 yet). The experience on freefall > > proves that this concept is workable, although there's still a tool > > missing where a user can invite and de-invite others into his group. > > > I assume you mean the 16 groups per user limit, eh? No. The 200 users per group limit. > Do you mean that in the new, post 2.2 code there's really _no_ > limit to the number of secondary groups that a user can belong to? No. There is now (effectively) no limit to the number of users who can belong to any secondary group, although the number will actually be something >=65536 users since the line length is prevented from growing beyond 256K for security reasons, which is fair enough. So far, the 16 groups per user is enforced by initgroups() et al remains, but I think it a candidate for being looked at as well. It seems that this is mostly driven by the NGROUPS #define in sys/param.h NGROUPS_MAX and KERN_NGROUPS (which is 18, not 16, for some reason which I haven't looked into). Unlike the 200 limit, though, a change here will affects the kernel, not just userland code. There may not be a way of making it "unlimited" without some significant redesign which may break POSIX or other design specifications (I don't know), but afaik there's no reason that this small limit could be raised to, say, 64. But beyond a solution that involves lifting it to a ridiculously high number, whatever limit is set is going to be arbitrary. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/