Re: Vnode scope

["Matt W. Benjamin" <matt%linuxbox.com@localhost>]

Hi,

So long as the implementation eventually defers to kauth with the defined 
credential information, such that any FS which wishes to implement a listener 
may do so, it doesn't then seem to present a real problem (e.g.) openafs.  It's 
more to implement--but in fact, I have thought that implementing a kauth 
listener provides a way to attactively implement openafs PAGs, so we would 
presumably do it anyway.

Thanks,

Matt

----- Original Message -----
From: "Elad Efrat" <elad%NetBSD.org@localhost>
To: "Matt Benjamin" <matt%linuxbox.com@localhost>
Cc: "Ken Hornstein" <kenh%cmf.nrl.navy.mil@localhost>, 
tech-kern%NetBSD.org@localhost
Sent: Monday, May 11, 2009 9:30:22 PM GMT -05:00 US/Canada Eastern
Subject: Re: Vnode scope

Matt Benjamin wrote:

> Anyway, it does seem problematic to require every fs to present a
> normalised representation of ACLs.  However, my impression was that
> kauth was sufficiently flexible as to allow (for this use) the fs to
> implement it's own security policy though the implementation of new
> listener(s).  Would that be a possibility for vnode scope?

Expected usage of the vnode scope, as suggested by Apple, is heavy, so
we're hoping to not have to require each file-system to provide its own
kauth(9) listener (which is, IMO, much more than asking for a normalized 
representation).

Either way, as my reply to Andrew states, we don't have to do that
though, if we split the access control decision to (what I believe is)
a more realistic representation: "is this operation even possible", and
"is this operation allowed". The first will rule out immediately, the
second will be passed to kauth(9) listeners for consulting