Re: Vnode scope implementation

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> Hey,
> 
> Sorry for the delay, I was a bit busy.
> 
> I don't see any reason to hold with implementing the vnode scope just
> because we can't control operations on a remote host. Therefore, I'll
> give it a few more days (just in case) before moving forward.

what will you do for nfs etc, by "moving forward"?
do nothing and give up mandating the use of vnode scope?

YAMAMOTO Takashi

> 
> Thanks,
> 
> -e.
> 
> Elad Efrat wrote:
>> On Tue, Aug 4, 2009 at 2:07 AM, YAMAMOTO 
>> Takashi<yamt%mwd.biglobe.ne.jp@localhost> wrote:
>> 
>>>> but IIUC it can prevent what the
>>>> remote file-system would allow
>>> sometimes it can, but in general it can't.
>>>
>>> 1. a client sends a request to a server.
>>> 2. the server decided to allow the operation, and actually process it,
>>>  and return the result to the client.
>>>
>>> ie. you don't have a chance to pass "fs_decision" to kauth.
>> 
>> Ugh, the above was an obvious typo on my part. I agree, we don't have
>> a chance to pass fs_decision to kauth(9) because the remote server
>> will already perform the operation.
>> 
>>>> Should we enforce that
>>>> limitation on all file-systems, or make remote file-systems an
>>>> exception? Veriexec sets a precedent of the latter, which I think
>>>> makes sense. Do you have something else in mind?
>>> i'm not sure if "remote file-systems or not" is a good classification
>>> method.
>> 
>> How else would you classify it? and you still don't answer the
>> question of whether you have a solution that will not be considered
>> "broken". ;)
>> 
>> Thanks,
>> 
>> -e.