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. Thor
thor,
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:
http://netbsd.gw.com/cgi-bin/man-cgi?kauth++NetBSD-current
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
kauth_cred_t objects.
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:
http://netbsd.gw.com/cgi-bin/man-cgi?secmodel++NetBSD-4.99.20
it's opened with:
DESCRIPTION
NetBSD provides a complete abstraction of the underlying security
model used with the operating system to a set of kauth(9) scopes
and actions.
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?
-e.