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 <[EMAIL PROTECTED]>
> > Subject: ucred.cr_gid
> > Message-ID: <[EMAIL PROTECTED]>
> > 
> > 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.

Ruslan Ermilov          Oracle Developer/DBA,
[EMAIL PROTECTED]           Sunbay Software AG,
[EMAIL PROTECTED]          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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to