Date: Thu, 13 Dec 2001 10:11:17 -0500 From: "Brian F. Feldman" <green@freebsd.org> To: Dima Dorfman <dima@trit.org> Cc: Robert Watson <rwatson@freebsd.org>, arch@freebsd.org Subject: Re: MFC'ing xucred definition Message-ID: <200112131511.fBDFBHE78634@green.bikeshed.org> In-Reply-To: Message from Dima Dorfman <dima@trit.org> of "Thu, 13 Dec 2001 03:58:58 GMT." <20011213035903.AA8603E2F@bazooka.trit.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dima Dorfman <dima@trit.org> wrote:
> Robert Watson <rwatson@freebsd.org> wrote:
> > I've actually been thinking about modifying xucred in -CURRENT to export
> > additional information from a kernel ucred, such as real and saved ids,
> > now that we have that information in ucred.
>
> Some users of xucred wouldn't know what to do with these extra fields,
> since they just use xucred to pass a uid/gid to/from the kernel. The
> NFS export stuff is one of these, I think.
>
> > Before we MFC xucred, it
> > might make sense to make a few tweaks to xucred, including changing the
> > first _cr_unused0 into a version number, and teaching applications how to
> > understand the version number.
>
> I don't know what other tweaks you had in mind (perhaps making it
> larger?), but the version number seems like a good idea.
>
> I've attached a patch that makes the first field a version number, and
> teaches the existing applications about it (mostly, it teaches them
> set the version when writing an xucred, and return EINVAL if it
> doesn't match when reading an xucred). It compiles and seems to run,
> but I have not done extensive testing with it. Please review.
Yes, this looks like just what I intended we should do with xucred {} if we
ever decided to want to export more fields. I like the changes, except for
a few smaller things. In the interest of compatibility, XUCRED_VERSION
should start at 0, or it will needlessly break several applications. The
other is that I am curious why the new field is named cr_xversion and not
just cr_version. I'd be much more comfortable with cr_version, which would
coincide with the naming of the #define you chose of XUCRED_VERSION.
> (Note that this patch changes something inside lomac which looks like
> it was copied verbatim from uipc_usrreq.c. I don't know anything
> about lomac, but my guess is that this code should be kept somewhat in
> sync (although I haven't seen any posts/warnings to that effect). If
> anyone can shed any light on this, I'd appreciate it).
That is indeed the case. That bit of code would have to either have been
copied for use there or modified wholesale (which would be somewhat evil).
Anyway, all seems to be correct even if I'd rather those two small changes
were made.
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'
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?200112131511.fBDFBHE78634>