tech-kern archive

[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
Takashi<> 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?

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

yes, and we have described the implications very well.



Home | Main Index | Thread Index | Old Index