[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Vnode scope implementation
> 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?
> 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
>> 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". ;)
Main Index |
Thread Index |