From owner-freebsd-current Wed Jun 27 0: 9:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id DA7A937B406; Wed, 27 Jun 2001 00:09:15 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f5R795J04362; Wed, 27 Jun 2001 10:09:05 +0300 (EEST) (envelope-from ru) Date: Wed, 27 Jun 2001 10:09:05 +0300 From: Ruslan Ermilov To: Robert Watson Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFR] ucred.cr_gid Message-ID: <20010627100905.A2097@sunbay.com> Mail-Followup-To: Robert Watson , arch@FreeBSD.org, current@FreeBSD.org References: <20010626134456.B86114@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Tue, Jun 26, 2001 at 11:18:56AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 > > 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 '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-current" in the body of the message