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 Message-ID: <Mutt.19961227140001.davidn@sdev.blaze.net.au> In-Reply-To: <Pine.FBS.3.93.961226183435.24907A-100000@dingo.its.enc.edu>; from Charles Owens on Dec 26, 1996 19:30:43 -0500 References: <199612262141.WAA00148@uriah.heep.sax.de> <Pine.FBS.3.93.961226183435.24907A-100000@dingo.its.enc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19961227140001.davidn>