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.
> Date: Fri, 22 Jun 2001 18:05:09 +0300
> From: Ruslan Ermilov <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: ucred.cr_gid
> Message-ID: <[EMAIL PROTECTED]>
> Mail-Followup-To: [EMAIL PROTECTED], [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.
> 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.
> 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?
> 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'll try to give you a detailed code review in a couple of days.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
