On Thu, Feb 01, 2007 at 02:31:41PM -0800, Bill Studenmund wrote:
>On Thu, Feb 01, 2007 at 01:49:07PM -0500, George Georgalis wrote:
>> On Mon, Jan 29, 2007 at 10:39:15PM -0800, Bill Studenmund wrote:
>> >
>> >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!
>
>Note: in re-reading your message, I realized I answered something a little 
>different. With what I describe, we can limit access based on export 
>point. So if you got your file handle from a r/o export, you always can't 
>write. That's not the same thing as enforcing mode masks on NFS clients, 
>but it's most likely what people really want.

That's fine. I wasn't so much wanting masks, as
wanting unavailibity of parrent directories after
a "sub-filesystem directory export."

>> 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?
>
>NFS exporting an NFS mount can run into the problem that file handle sizes 
>are fixed (as I recall) for NFS v2, and to add this extra info, we'd have 
>to gobble up "reserved" space in the input file handle. True, most file 
>handles won't care, but some may.
>
>Also, why would you want to do this? As an admin, I'd dislike it if you 
>shared my export, because then I (the admin of the share you're mounting 
>as a client) lose control of access.

It has been frustrating not being able to see an iso
mount that was within an nfs export.

As far as control and re-export of nfs; we only
export (r/w or ro) to networks we trust for the
purpose, and I'd treat that the same way as ssh
keys. When we accept a pub key, we trust the user
not to share his private key. besides once we export
there's nothing stopping the client from abusing the
resource as a samba share or some other mechinism.

I don't have an immedate need to re-export nfs, but
it may be better than setting up a masq gateway to
reach another network, eg a central LAN nfs server
may host ro and r/w points, and also re-export a ro
nfs from a public server on the internet---one host
is simpler for clients/users.

Seem to recall problems trying to mount nfs through
a masq gateway, but that may have been firewall
configuration.

// George



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