Re: Vnode scope implementation

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

hi,

> On Tue, Aug 25, 2009 at 11:43 AM, YAMAMOTO
> Takashi<yamt%mwd.biglobe.ne.jp@localhost> wrote:
> 
>>>> does it mean the use of the vnode scope is optional and a filesystem is
>>>> free to choose not using it, right?
>>>
>>> No, what is your reasoning here?
>>
>> what do you mean by "No"?  it won't be optional?
>> it can't be mandated because it's simply impossible for some filesystems.
> 
> Just because it's impossible for *some* file-systems doesn't mean we
> shouldn't be doing it for *all* file-systems. If NFS has limitations,
> why should they affect file-systems that do not?
> 
> I would rather have a note that says "security policies can't
> explicitly allow operations on NFS mounts, as the server gets the
> final word", than one that says "the vnode scope is not implemented
> for ufs, ext2fs, tmpfs, etc. because NFS has certain limitations it
> forces on what security policies can do."

i guess that you misunderstand what i said.
i'm merely saying that filesystems should be allowed to choose not
using the vnode scope.  what's wrong with it?

> 
>>> It means that if a file-system's security policy effectively comes
>>> from a host that you have no control over, you can not explicitly
>>> allow an operation because you don't have the last word, but you can
>>> certainly short-circuit and deny the operation.
>>
>> sometimes you can't short-circuit with the suggested api because you
>> need to get "fs_decision" first.
> 
> We can pass -1 for fs_decision in the NFS case, or altogether leave
> NFS out of the plans for now. I don't think it has that much weight at
> this point.

what does -1 mean?

nfs is an important filesystem when designing filesystem interface.

YAMAMOTO Takashi

> 
> -e.