Date: Wed, 27 Jun 2001 10:09:05 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFR] ucred.cr_gid Message-ID: <20010627100905.A2097@sunbay.com> In-Reply-To: <Pine.NEB.3.96L.1010626111503.98714H-100000@fledge.watson.org>; from rwatson@FreeBSD.org on Tue, Jun 26, 2001 at 11:18:56AM -0400 References: <20010626134456.B86114@sunbay.com> <Pine.NEB.3.96L.1010626111503.98714H-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 26, 2001 at 11:18:56AM -0400, Robert Watson wrote: > > On Tue, 26 Jun 2001, Ruslan Ermilov wrote: > > > Could someone please take a look at it before I commit this? > > I won't get a chance to properly review this until I'm at USENIX tomorrow. > If you're willing to hold off for about a week, I'd be happy to give it a > fairly detailed review: I had some thoughts of doing this when I > originally merged ucred and pcred a few weeks ago, but decided to hold > 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 > very sensitive to subtle semantic changes on calls--on the other hand, I > think moving towards making the supplementary groups being independent > from the effect gid is a good goal, as it simplifies our credential code, > and improves compatibility. > At least one compatibility issue here is that it's no longer possible to use initgroups(3) to set the effective group ID. > > Date: Fri, 22 Jun 2001 18:05:09 +0300 > > From: Ruslan Ermilov <ru@FreeBSD.org> > > To: arch@FreeBSD.org, current@FreeBSD.org > > Subject: ucred.cr_gid > > Message-ID: <20010622180509.D31008@sunbay.com> > > Mail-Followup-To: arch@FreeBSD.org, current@FreeBSD.org > > > > Hi! > > > > The attached patch replaces ucred.cr_groups[0] with ucred.cr_gid. This > > is mostly needed for POSIX alignment. setegid(2) etc. should not change > > supplementary groups set. > > > > Also, type of <grp.h>'s group.gr_gid changed to a more natural gid_t > > (also as in POSIX). > > Sounds good, I think this change was bandied about once before and perhaps > simply didn't get committed. > Some of the assorted changes were committed as part of Hesiod import from NetBSD. > > getgrouplist(3)'s and initgroups(3)'s prototypes fixed. getgrouplist(3) > > has been also fixed to not duplicate the primary group, and always > > return number of suplementary groups, even if ngroups is zero (similar > > to sysctl(3)). > > Having not looked at the patch yet, just need to make sure I point out the > following areas that are sensitive to this type of change: linux and other > ABI emulation, where semantic mapping of this sort is already performed, > as well as userland applications managing groups. > I think my patch handles these. > > Assorted changes: > > > > cmsgcred.cmcred_egid New > > This is an ABI change that will break applications compiled for older > versions of FreeBSD. Is this a change that applications can detect via > some sort of sizeof/sanity check on cmsg results? > I can't see how this would break old applications. > > kproc_info.ki_gid New > > portal_cred.pcr_gid New > > xucred.cr_gid New > > > > I'm not sure what to do with xucred. > > Probably reflect changes made in ucred fairly closely. > I mean, I'm not sure if we should preserve the 4.2's size of this structure or no, and if so, how to actually do it. Theoretically, this could be done by placing cr_gid in a union with _cr_unused1 and #define that untangles the fact that cr_gid is in a union, but that define would have to be ``#define cr_gid ...'' which is too bad. > I'll try to give you a detailed code review in a couple of days. > Thanks! Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age 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?20010627100905.A2097>