tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Vnode scope implementation



hi,

> Am 21.08.2009 um 12:19 schrieb 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?
> 
> I think it's quite clear that in the case of networked file systems it  
> is always the serving machine that has "the last word" on security  
> decisions and restrictions.  So while a nfs client could tighten  
> restrictions, it can not loosen them.  I think this is a fact we have  
> to live with.

sure.  i'm asking how will we live with the fact.

YAMAMOTO Takashi

> 
>>
>> 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.


Home | Main Index | Thread Index | Old Index