Subject: Re: exporting -ro nfs
To: None <tech-kern@netbsd.org>
From: George Georgalis <george@galis.org>
List: tech-kern
Date: 02/01/2007 13:49:07
On Mon, Jan 29, 2007 at 10:39:15PM -0800, Bill Studenmund wrote:
>On Mon, Jan 29, 2007 at 03:53:45PM -0500, George Georgalis wrote:
>> On Mon, Jan 29, 2007 at 09:47:59AM -0800, Bill Studenmund wrote:
>> >
>> >The idea would be to 1) add some sort of long-term key that is passed in 
>> >with each export. Something that is stable across boots. 2) add space in 
>> >the file handle to indicate which export point a file handle came from, 
>> >and 3) add some sort of authentication so that we can tell if it's likely 
>> >the file handle has not been tampered with. The thought is to do something 
>> >so that it's harder to forge file handles.
>> 
>> 
>> Is it possible to wrap filesystem access so that the client must
>> respect mode settings like the local users? With a "mask" that
>> sets mode 000 for files and 111 for directories above the mount
>> point? Obviously -ro exports would get mode 222 removed from
>> everything, in addition to whatever --maproot was configured to
>> do.
>
>That's a main part of the idea. We now have enough info to make the 
>different exports from the same server file system behave as if they are 
>different file systems.
>
>> Maybe "that wouldn't be NFS" but would such a derivative network
>> filesystem be all that difficult?
>
>It would still be NFS.
>
>> NFS is nice because it's simple and works reasonably well. If
>> I could get 95% the performance and more robust "exports"
>> configuration, I'd use it.
>
>There might be a performance change, but it'd still be the exact same NFS
>we have now. Given all the other things in NFS, I doubt there'd be much 
>performance impact. As Jason mentioned, the main idea here is that instead 
>of having "mount" info in the file handle, we have some form of "export" 
>info. It'd mean a changed multiplexing/demultiplexing, but it wouldn't be 
>hard to do.

Hey that's great!

If/when this gets in place no doubt exports(5) will be updated.
It might be worthwhile to clarify you can only export a local
filesystem, ie an iso vnode mount or nfs mount from another host
won't export... as I'm writing this I wonder if this restriction
will continue under the new system? if the file handle contains
the export info we are no longer bound to the local filesystem
right?

In retrospect, if user was required to specify the _filesystem_
in exports, the workings (and exposure) of the system would
be clearer all around.

// George



-- 
George Georgalis, systems architect, administrator <IXOYE><