Re: Vnode scope

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, May 09, 2009 at 04:42:16PM +0300, Elad Efrat wrote:
 > I would like to implement the vnode scope so we can use kauth(9) to
 > authorize file-system related operations.
 > 
 > There are generally two ways we can go about that:
 >   - Move access control to the VFS layer
 >   - Keep access control in file-system specific code
 > 
 > At this point I'd like to discuss only the first.

That seems like an unwarranted assumption, and also not a good idea.

 > Moving access control to the VFS layer requires the following:
 >   - Each file-system must provide means to convert its own
 > permissions, ACLs, etc. to a normalized form. At the moment, for
 > NetBSD and standard permissions, this is pretty much done using
 > VOP_GETATTR() and isn't an obstacle.

This is the wrong approach. First of all, for most parts of most code
paths you want an abstraction for permissions, the same way that
you've already set up abstractions for credentials.

Only in the place where (real, non-abstract) credentials are tested
against (real, non-abstract) permissions does it make sense to talk
about canonical or normalized forms. And then in those cases, in
general you want a canonical form for credentials, not a canonical
form for permissions.

In general, permissions are a mapping from pairs (credentials, object)
to boolean. One can store or represent this mapping in a number of
ways (capabilities, ACLs, traditional Unix permissions, etc.) but it
relies on a coherent concept of credentials. I can "normalize" the
permissions on my FS all you like, but it doesn't *mean* anything
unless the credentials we use as a basis represent a shared
understanding. That is, what you understand by "uid 5" better be the
same as I mean when I say it. Otherwise, when I hand you a
"normalized" ACL that says "uid 5 can jump up and down and whistle
Dixie", your interpretation of it won't be correct.

However, given a canonical form for credentials, there's no need for
normalizing anything: you present the credentials to the FS and it
reads them and returns yes or no based on its internal data
structures, and that's the beginning and end of it.

Your other mails seem to suggest that we shouldn't bother worrying
about abstract credentials because everything uses only traditional
Unix permissions. That's a horrible cop-out. I thought one of the
points of kauth was to *avoid* hardwiring outdated assumptions into
the design.

Meanwhile, making every FS that wants to use some other kind of access
control implement a kauth listener to substitute the right access
check results in by sleight-of-hand... is really a bad plan. Access
control code *has* to be simple and straightforward.

It seems to me that if you want to be able to override the permissions
checks by specific kauth configuration (which seems like a really bad
idea too, but apparently that's what kauth's about) then this logic
needs to be per-FS specifically because it means different things to
different FSes.

-- 
David A. Holland
dholland%netbsd.org@localhost