[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Vnode scope implementation
Am 25.08.2009 um 22:00 schrieb YAMAMOTO Takashi:
On Tue, Aug 25, 2009 at 11:43 AM, YAMAMOTO
does it mean the use of the vnode scope is optional and a
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
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 explicitly
allow an operation because you don't have the last word, but you
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
what does -1 mean?
nfs is an important filesystem when designing filesystem interface.
yes, and we have described the implications very well.
Main Index |
Thread Index |