Date: Wed, 27 Jun 2001 18:40:53 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Ruslan Ermilov <ru@FreeBSD.ORG> Cc: Robert Watson <rwatson@FreeBSD.ORG>, arch@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [CFR] ucred.cr_gid Message-ID: <Pine.BSF.4.21.0106271733290.21476-100000@besplex.bde.org> In-Reply-To: <20010627100905.A2097@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0106271733290.21476-100000>