Vnode scope

[Elad Efrat <elad%NetBSD.org@localhost>]

Hi,

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.

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.

  - Each file-system's access() routine should NOT implement any kind
of access control, but instead enforce file-system specific
limitations. For example, if the file-system does not support "write",
then it should deny all write requests -- but it should never make any
decision based on uid/gid/etc. Remember that this makes sense because
access control is in the VFS layer, not file-system specific code.

  - We replace VOP_ACCESS() calls with vnode_authorize() or such,
mainly because we need the additional "dvp" argument that VOP_ACCESS()
doesn't take. We also sprinkle various vnode_authorize() calls in the
VFS layer where they're now missing: for example, we can call
vnode_authorize() in vfs_syscalls.c:do_sys_unlink(), and remove
Veriexec-specific code (and fileassoc, if we really want to). It also
allows us to enforce ACLs that are file-system independent (ie.,
implemented using fileassoc(9)).

  - In vnode_authorize(), we first call VOP_ACCESS() to get an answer
from the file-system. If the file-system returns non-zero, we return
that error code. Otherwise, we VOP_GETATTR() to get a normalized
representation of the permission bits/ACL and make a decision based on
that (for now it'll probably be just vaccess() without the kauth(9)
call). We then check if we have at least one secmodel: if we don't, we
return that decision (that way, we don't allow any user access to
sensitive files just because a secmodel isn't present). If we do, we
pass the arguments (vp, dvp, decision, errorp) to kauth(9), so it can
flip the decision (say, uid 1337 always gets access, uid 1234 never
gets access). If kauth(9) returns non-zero, we return EACCES or the
error code in errorp if it's not -1.

Limitations:
  - It's confusing that VOP_ACCESS() doesn't check access control, but
we can document that...
  - ACLs are limited to what our normalized representation can
represent, but that's not a problem for now I guess
  - Lots of changes to replace VOP_ACCESS() to vnode_authorize()

Any thoughts on the above? anything I missed? do we want to do it that
way? anything we should take into consideration?

Thanks,

-e.