From owner-freebsd-arch Wed Jun 27 1:42:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id C04C637B401; Wed, 27 Jun 2001 01:42:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA20407; Wed, 27 Jun 2001 18:42:48 +1000 Date: Wed, 27 Jun 2001 18:40:53 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Ruslan Ermilov Cc: Robert Watson , arch@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [CFR] ucred.cr_gid In-Reply-To: <20010627100905.A2097@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 27 Jun 2001, Ruslan Ermilov wrote: > On Tue, Jun 26, 2001 at 11:18:56AM -0400, Robert Watson wrote: > > ... > > off. I'm generally fairly positive about this change, but would be > > interested in hearing Bruce's thoughts on any compatibility issues, in > > particular, with respects to the behavior of userland processes with > > expectations about the old behavior. Obviously, this is a change that is Me too :-). I don't know much about this except that it is related to longstanding bugs in gid management. > At least one compatibility issue here is that it's no longer possible > to use initgroups(3) to set the effective group ID. I think this shows that keeping the egid in group lists is intentional. The only bug in the current implementation seems to be that NGROUPS_MAX is 1 too small. The first gid in group lists is conventionally always the egid, but there must be space for NGROUPS_MAX "supplementary" groups, so statically allocated group lists must have size NGROUPS_MAX+1, but they currently (all?) have size NGROUPS_MAX. POSIX.1-200x documents this for getgroups(2) -- returning the egid is optional, and getgroups() may return {NGROUPS_MAX}+1 entries. I think the semantics of getgroups(), setgroups() and initgroups() shouldn't be changed. To set a really supplemental gid (one not affected by setegid(), setgroups() must put the gid in the list after the first entry even if it is is the egid). In the kernel, the problem is not really changed by keeping the egid in a separate variable. I currently slightly prefer keeping it in group lists. Binary compatibility could be preserve by hacking NGROUPS_MAX to NGROUPS_MAX - 1 (ugh). I don't see how to preserve source level compatibility. You have to change either the semantics by not putting the egid in group lists, or NGROUPS_MAX to NGROUPS_MAX+1 in many places. Portable applications need the latter change anyway. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message