From owner-cvs-all@FreeBSD.ORG Fri Nov 18 08:09:57 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95C1F16A41F; Fri, 18 Nov 2005 08:09:57 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3026043D4C; Fri, 18 Nov 2005 08:09:46 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 09:09:44 +0100 Date: Fri, 18 Nov 2005 09:09:44 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Bruce Evans In-Reply-To: <20051118074117.A96615@delplex.bde.org> Message-ID: <20051118085549.S10504@beagle.kn.op.dlr.de> References: <200511171219.jAHCJJw6079767@repoman.freebsd.org> <20051117131533.H77687@fledge.watson.org> <20051118074117.A96615@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 18 Nov 2005 08:09:44.0767 (UTC) FILETIME=[6F6BDCF0:01C5EC17] Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Robert Watson , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/rpc.lockd kern.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2005 08:09:58 -0000 On Fri, 18 Nov 2005, Bruce Evans wrote: BE>On Thu, 17 Nov 2005, Robert Watson wrote: BE> BE>> On Thu, 17 Nov 2005, Hartmut Brandt wrote: BE>> BE>> > harti 2005-11-17 12:19:19 UTC BE>> > BE>> > FreeBSD src repository BE>> > BE>> > Modified files: BE>> > usr.sbin/rpc.lockd kern.c BE>> > Log: BE>> > When a user is in more than 16 groups the call to authunix_create() will BE>> > result in abort() beeing called. This is because there is a limit of BE> BE>Is this for a remote user? {NGROUPS_MAX} is 16, so a local user cannot be BE>in more than 16 groups, and there are local bugs involving the egid hack BE>which break other things for users in even 16 groups, so more than 14 or BE>15 groups should not be used. I have to integrate a number of FreeBSD and Linux machines into an active directory environment. This has a couple of thousands of users and around 2500 groups. It extensively uses groups to control access to files on the file servers, so, for example, my account ends up in beeing in 36 groups (at the moment). I have bumped NGROUPS_MAX to 64 and most things work. BE> BE>The egid hack is "#define cr_gid cr_groups[0]". This requires putting BE>the egid in groups lists as the first entry. IIRC, it is optional in BE>POSIX for the egid to be in groups lists, and the implementation is BE>broken since it doesn't remove all duplicate entries. So instead of 16 BE>_supplemental_ groups (extra groups other than the egid), FreeBSD has BE>only 14 or 15 supplemental groups depending on whether the optional BE>egid is included once or twice in groups list. I think 1 duplicate BE>gets removed somewhere, so 15 groups work in practice, but reducing BE>{NGROUPS_MAX} to 15 still wouldn't be POSIX conformant since the 16th BE>groups is visible in some cases. BE> BE>> > the number of groups in the RPC which is 16. When the actual number of BE>> > groups is too large it results in xdr_array() returning an error which, BE>> > in turn, authunix_create() handles by just calling abort(). BE>> > BE>> > Fix this by passing only the first 16 groups to authunix_create(). BE> BE>If it is an RPC limit, then shouldn't the protocol require senders to BE>not send more and say what to do if they do? It is a limit in the RPC. See . The patch limits the FreeBSD side of rpc.lockd to send not more than 16 groups (these are groups 1-16 of the group array). If it receives more than 16 it will probably drop the request (I've not tried it). It just 'should not happen'. BE> BE>> It might be nice to add a comment to params.h by the definition of BE>> MAXGROUPS pointing at this and any other known gotchas. We've had a number BE>> of requests BE> BE>MAXGROUPS doesn't exist. Do you mean NGROUPS_MAX or the compatibility BE>cruft NGROUPS? I think increasing NGROUPS_MAX would increase compatibility BE>for servers and reduce it for clients. Works fine for me (on the client side). Before increasing it, I could not even login, because setgroups() failed in login(1). BE>> to support significantly extended groups in FreeBSD, and I did some initial BE>> hacking on variable length group storage for credentials but didn't bring BE>> it to completion. If this is something you're interested in looking at BE>> though, I'm happy to spread the pain :-). BE> BE>The pain for making file descriptor starage variable has been spread BE>across about 20 years. Making it just larger but keep it static would help a lot. 16 groups just isn't enough for larger environments (another unix-like os uses 63 or 64). harti