Re: CVS commit: src/sys

[Elad Efrat <e%murder.org@localhost>]

Thor Lancelot Simon wrote:

> Sometimes people change their minds.  Sometimes it takes them some
> time to decide to change their minds.

I have heard this argument before and my answer to it remains the
same: when a technical decision is "to break" or "not to break",
it doesn't take a genius to choose between the two. :)

> I have a tremendous amount of difficulty understanding why this is any
> kind of problem, rather than as simply the usual give-and-take, including
> mistakes, corrections, and so forth, that inevitably occurs in any large
> software project.

I'll help you understand, then.

in a large software project, where multiple people are working on
various parts of the tree, a certain amount of coordination and
cooperation is required to ensure -- especially to the users -- that
the state of the tree remains stable as possible, and no one subsystem
or design decisions step on the toes of another. in case where this is
inevitable, a technical decision is required to choose whose toes go on
top.

kauth was designed, from the ground up, with opacity in mind. this
opacity is what gives it its flexibility to provide the cool stuff it
does, such as pluggable security models and so on. this is not part
of the original apple design: it was designed especially for netbsd,
which has a "hybrid" kauth with some concepts from other frameworks.

when one person introduces changes to a subsystem, in this case kauth,
to simplify a code path of a non critical syscall, and as a result
breaks one of kauth's core elements, and without prior discussion, he
first violates the development model of a large scale software project,
and that is what you, the project, and the users should care about.

if dsl@'s changes would go up for public discussion, at least I or other
developers or users would have a chance of asking for reasoning and
expressing opinion before the aforementioned changes go in the tree.
however, that did not happen, and what we're doing now is, again,
discussing whether or not something that already happened should happen.
I could go on and on about being proactive and having peer review, but
some people do not seem to give a rat's ass. so I merely point out that
these changes affect *only* the people who use netbsd, who now will get
*less* than what they could *if* these changes would not go in the tree.

that said, I think it's quite obvious that if this would go up for
public discussion it would be shot down rather quickly. it already
happened once in the not so far past:

http://mail-index.netbsd.org/tech-kern/2007/02/18/0008.html

> As regards the kauth documentation I think something in the tree,
> like the documentation traditionally kept in /usr/share/doc/psd, would
> be ideal.  Nobody can claim not to understand the rationale if it's
> written up that way; whereas now, a lot of people don't seem aware of
> the rationale for what was done at all, though the documentation of
> what was done, itself, is perfectly fine.

on one hand, you're right that it is not crystal clear that opacity
is a core design of kauth in the kauth(9) man page. however, the way
from here to saying the documentation is "poor" is quite far.

if one would care enough, he'd go to google and look for kernel
authorization:

http://www.google.com/searchq=kernel+authorization

where the first hit is the mailing list post I mentioned before, where
I do mention opacity as important. the 4th hit is this:

http://www.securityfocus.com/infocus/1878/3

which is the page in my paper with the description of kauth's
implementation, where I also say this:

    Part of that work included merging the contents of the ucred and
    pcred structs into a single, opaque (as possible) type called
    kauth_cred_t.

(the "as possible" was added after 'struct kauth' was forward declared
in a header file.)

the second hit, btw, is apple's tn2127, where they say this:

    credentials — Credentials are the information that identifies an
    actor. Credentials are specified by an opaque type, kauth_cred_t.
    There are numerous accessor functions that let you operate on this
    type.

so I think, all in all, that rather than the documentation itself, the
attempt to justify the change by claiming "one may not know it is a
core element" is poor itself. :)

but then again, what do I know, expecting people to ask, investigate,
ask for peer review and comments, and god forbid even google (!) before
changing a critical kernel subsystem... sheesh!

-e.