Re: Vnode scope implementation

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

On Wed, Jul 22, 2009 at 2:05 PM, YAMAMOTO 
Takashi<yamt%mwd.biglobe.ne.jp@localhost> wrote:
> hi,
>
>> On Wed, Jul 22, 2009 at 11:05 AM, YAMAMOTO
>> Takashi<yamt%mwd.biglobe.ne.jp@localhost> wrote:
>>
>>> i have a few more questions.
>>>
>>> - what about the locking protocol?
>>>  in other words, what can and can't a listener do?
>>>  while i think that it's a weak area of our kauth in general,
>>>  i'm curious especially about this scope because it likely involves
>>>  vnode locks.
>>
>> That is indeed a weak point with kauth(9) at the moment. If you
>> remember, a long time ago we decided to add an assertion for being
>> able to sleep in kauth_authorize_action() or such, and quickly gave up
>> on it. :)
>>
>> I was under the impression that the VFS locking protocol is about to
>> change at some point, which resulted in the decision to place the
>> authorization call inside the file-systems rather than outside as I
>> originally proposed. Since, at this point, I don't know exactly what
>> the new locking protocol will be, I can't really comment on it.
>
> i'm asking for the current locking protocol in your patch,
> not the future one.  (eg. the vnode might or might not be locked.
> a listener should not touch it at all. :-)
>
> or you will not commit the change until "the new locking protocol"
> is available?

The locking considerations were made for changes inside the access
routine of each file-system, which requires a locked vnode (i.e., the
vnode passed to the listener is locked). The rest of the diff,
affecting tmpfs (but we might be able to infer from it for other
file-systems), places the kauth(9) calls, in addition to access, in
setattr (same locking semantics as access), and lookup (where during
the lookup IIUC the vnode is locked as well).

In other words, it's safe for the listener to "query" the vnode, but,
similar to other parts of kauth(9), I'm not sure about sleeping while
holding it locked. :)

>>> - what's your plan about filesystems for which it can might impossible
>>>  to alter filesystem's decisions?  eg. nfs
>>
>> I don't have a plan for NFS yet. Does it affect the kauth(9)
>> integration with all of our other file-systems, though?
>
> a design which works only for some of filesystems is considered broken,
> or less useful at least.  can you please provide a rough plan?

Well, I'm not too familiar with NFS, so let's see. Where do things
start falling apart when NFS comes into the equation?

Thanks,

-e.