From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 14:45:51 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8498D16A4CE; Sat, 13 Dec 2003 14:45:51 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 477BA43D1F; Sat, 13 Dec 2003 14:45:49 -0800 (PST) (envelope-from adam@migus.org) Received: from ludo.migus.org ([68.55.80.136]) by comcast.net (rwcrmhc11) with ESMTP id <2003121322454801300cc2cre>; Sat, 13 Dec 2003 22:45:48 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6DAFEA103B; Sat, 13 Dec 2003 17:45:48 -0500 (EST) Received: from ludo.migus.org ([127.0.0.1]) by localhost (ludo.migus.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 98125-02; Sat, 13 Dec 2003 17:45:47 -0500 (EST) Received: from migus.org (ganyopa.migus.org [192.168.4.2]) by ludo.migus.org (Postfix) with ESMTP id 54006A103A; Sat, 13 Dec 2003 17:45:47 -0500 (EST) Message-ID: <3FDB969D.1090606@migus.org> Date: Sat, 13 Dec 2003 17:45:49 -0500 From: "Adam C. Migus" Organization: Migus Dot Org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <3FDB731A.7020301@web.de> In-Reply-To: <3FDB731A.7020301@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at migus.org cc: Robert Watson cc: Kris Kennaway Subject: Re: [RC1] Login not possible X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2003 22:45:51 -0000 Klaus-J. Wolf wrote: > Excuse me, but the limit of a maximum of 16 group memberships per user > has not been known to me. It would be a good idea to document it > somewhere. > > I know a number of persons who will run into problems because their > idea of proper system architecture requires certain persons to be a > member of a higher amount of user groups. Until now, it might not have > worked, but the day it finally crashes and nobody can log in anymore, > will not make them happy. > > There should be an option, somehow. > > Robert Watson wrote: > >> FWIW, I think that failing here is the right thing to do (since >> otherwise >> the kernel silently changes the access control rights of processes), but >> that the failure error is a bit obscure. That said, the >> setusercontext() API isn't really set up to provide more detailed >> error information, so >> we'll need to expand the API. I wonder if it would make sense to modify >> the pw/etc commands to generate warnings if they discover a user in too >> many groups... >> >> > Klaus, I think you'll find this documented in several UNIX books such as "The Design and Implementation of the 4.4BSD Operating System," for example. I believe it's regarded as "common knowledge" among UNIX folk. Whether it's right or wrong to regard it as such, document it per implementation or even have it as a limitation is debatable I suppose but it's there. I'm not sure who'd think that proper system architecture required more than 16 groups given UNIX has never offered it. Moreover I myself can't envision any security model in which such a constraint would be a core requirement which, would not cause more headaches than overall system security and integrity; but that's just me. For what it's worth the person who just replied to you (Robert Watson) works on a framework in the FreeBSD 5.x series that implements Mandatory Access Control (MAC) extensions. If you're interested in implementing a security policy complex enough to warrant more than 16 groups I think you'd be more successful in implementing an effective policy using something like MAC rather than Discretionary Access Controls (DAC). In summary it might be nice if UNIX had no limits but at least it provides options. :-) Adam