Subject: Re: exporting -ro nfs
To: None <firstname.lastname@example.org>
From: George Georgalis <email@example.com>
Date: 02/02/2007 17:14:00
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
>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
George Georgalis, systems architect, administrator <IXOYE><