Subject: Re: CVS commit: src/sys
To: None <email@example.com>
From: Elad Efrat <firstname.lastname@example.org>
Date: 06/23/2007 21:24:21
Thor Lancelot Simon wrote:
> On Sat, Jun 23, 2007 at 06:37:20PM +0100, Alistair Crooks wrote:
>> As a software developer, my answer to your question would be "no - if
>> the complete abstraction has been violated, then it will be harder to
>> build models on top of kauth". Has the complete abstraction been violated,
>> or just a part of it? Where is the documentation dealing with the
>> abstractions, the ways it fits into other kernel code, and the direction
>> forward for kauth?
> The documentation is poor, but I think the design principle that's been
> violated here is pretty obvious: don't expose kauth internals or security
> model internals to other code in the kernel, because they will inevitably
> abuse it. Authentication data should only *ever* be handled via accessors.
> We had that (albeit not in an ideally documented state) and changes like
> the current one break it. We should find a way to gain the performance
> advantage of the current change without exposing knobs code outside kauth
> has no business turning.
while I agree with what you're saying, I am very interested in hearing
what exactly is "poor" about kauth's documentation. this is the first
time I hear about it.
here is the kauth man page:
here is what it says about the interface:
Kernel Programming Interface
kauth exports a KPI that allows developers both of NetBSD and
third-party products to authorize requests, access and modify
credentials, create and remove scopes and listeners, and perform
other miscellaneous operations on credentials.
here is what it says about accessor/mutators:
Credentials Accessors and Mutators
kauth has a variety of accessor and mutator routines to handle
The following routines can be used to access and modify the user-
and group-ids in a kauth_cred_t:
[ list... ]
this is the secmodel(9) man page:
it's opened with:
NetBSD provides a complete abstraction of the underlying security
model used with the operating system to a set of kauth(9) scopes
shortly after (actually, 2 paragraphs down), there's this:
The problem with the above is that the interface ("can X do Y?")
was tightly coupled with the implementation ("is X Z?"). kauth(9)
allowed us to separate them, dispatching requests with highly
detailed context using a consistent and clear KPI.
what is so poor about it? what is missing?