From owner-svn-src-projects@FreeBSD.ORG Fri May 29 11:02:08 2009 Return-Path: Delivered-To: svn-src-projects@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0AA106564A; Fri, 29 May 2009 11:02:08 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 67B8A8FC08; Fri, 29 May 2009 11:02:08 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from besplex.bde.org (c122-106-151-9.carlnfd1.nsw.optusnet.com.au [122.106.151.9]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4TB24m1031391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 21:02:06 +1000 Date: Fri, 29 May 2009 21:02:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Brooks Davis In-Reply-To: <20090528182236.GC44818@lor.one-eyed-alien.net> Message-ID: <20090529200133.C1382@besplex.bde.org> References: <200905140650.n4E6oURU079910@svn.freebsd.org> <20090515122400.B15792@delplex.bde.org> <20090528182236.GC44818@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans Subject: Re: svn commit: r192087 - in projects/ngroups: lib/libc/gen lib/libc/rpc lib/libc/sys usr.bin/id usr.bin/newgrp usr.bin/quota usr.sbin/chown usr.sbin/chroot usr.sbin/jail usr.sbin/jexec usr.sbin/lpr/lpc X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 11:02:09 -0000 On Thu, 28 May 2009, Brooks Davis wrote: > On Fri, May 15, 2009 at 01:32:52PM +1000, Bruce Evans wrote: >> On Thu, 14 May 2009, Brooks Davis wrote: >> >>> Log: >>> Use to value returned by sysconf(_SC_NGROUPS_MAX) in favor of >>> NGROUPS_MAX or NGROUPS since POSIX says that NGROUPS_MAX represents a >>> lower bound on sysconf(_SC_NGROUPS_MAX). >> >> Actually, POSIX says that NGROUPS_MAX is identical to >> sysconf(_SC_NGROUPS_MAX) if it is defined (and the sysconf() succeeds). >> It is _POSIX_NGROUPS_MAX that gives the lower bound. _POSIX_NGROUPS_MAX >> is always 8, except under old versions of POSIX that don't require >> supplementary groups to be supported, where it is always 0. It is a >> bug for a POSIX implementation to define NGROUPS_MAX if its value is >> not always identical to sysconf(_SC_NGROUPS_MAX), or for a POSIX >> application to use NGROUPS_MAX unconditionally. > > According to the limits.h section of POSIX.1-2008, NGROUPS_MAX is a > Runtime Increasable Value and thus NGROUPS_MAX specifies the minimum > value that implementation may use. Gak, so it is. This makes the compile-time constant value NGROUPS_MAX (or any Runtime Increasable Value) almost useless in applications, since it is always defined but only gives the minimum value (for a "specific" implementation, whatever that is). NGROUPS_MAX can be used to allocate storage for functions like getgroups(2), but then the function will fail if the minimum value is smaller than the maximum and the calling process actually belongs to more than the minimum number of groups. Recovering from such failures would be harder (e.g., by trying again after doubling the allocation size) would be harder than avoiding the failure (by allocating enough storage using sysconf() to determine the amount needed). OTOH, the most efficient way might be to always allocate a large amount of storage initially (say PAGE_SIZE) and never look at {NGROUPS_MAX}. In POSIX.1-1990, {NGROUPS_MAX} is the _only_ Runtime Increasable Value. In POSIX.1-2001, there are lots more, but they are mainly for userland limits like {LINE_MAX} whose existence is a much larger bug than that of {NGROUPS_MAX}. > Given the constraint that the value > returned by sysconf(_SC_NGROUPS_MAX) not change during the life of a > process, there is probably a practical limitation that the underlying > limit be controllable at compile time or by a tunable, but not by sysctl. No one worries about sysctl()s and setrlimit()s breaking this constraint for other limits, but POSIX recently) added words to specify exactly how setting RLIMIT_NOFILE breaks^Waffects {OPEN_MAX}. > I'll look over and incorporate your other comments shortly. They were mainly about localizing the allocating of group lists. It would be harder to localize the more general allocation algorithms described above -- doubling the allocation size after it is found to be too small seems to need at least a separate loop for each function that detects the failure. I actually thought of such interfaces when I wrote the old mail -- use interfaces that allocate the storage internally, like asprintf(). getgrouplist() would be suitable for this treatment, and wouldn't even need to be renamed (it would allocate the storage iff its groups parameter is NULL). Syscalls couldn't do this, but getgroups(2) could become agetgroups(3). Bruce