Am 25.08.2009 um 22:00 schrieb 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 isfree 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?
I think all filesystems should use the vnode scope. If a filesystem does not use it, this will surprise the sysop.
It means that if a file-system's security policy effectively comes from a host that you have no control over, you can not explicitlyallow an operation because you don't have the last word, but you cancertainly 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 leaveNFS out of the plans for now. I don't think it has that much weight atthis point.what does -1 mean? nfs is an important filesystem when designing filesystem interface.
yes, and we have described the implications very well.
YAMAMOTO Takashi-e.