On Mon, Jan 29, 2007 at 09:47:59AM -0800, Bill Studenmund wrote:
>On Sun, Jan 28, 2007 at 02:16:53PM -0500, rick@snowhite.cis.uoguelph.ca wrote:
>> > No. File handles within an fs will still be used in the same way. We will
>> > just have a different mapping between the file system specific info and
>> > the on-wire NFS file handle.
>> 
>> I'm not sure how you are going to implement "different mapping"? Remember
>> that file handles are T stable, which means they refer to a file even
>> long after the file is deleted, must work across server reboots, etc.
>
>Yes and no. There's always a practical life to a file handle. At an 
>extreme, I doubt anyone cares about a file handle for a file system that 
>was destroyed over a decade ago. Or at least hardly anyone will.
>
>We can change the mapping of a file handle if we say we are making a 
>disruptive change to our NFS on-wire data. i.e. you have to unmount the 
>clients before updating the server then you can remount after the update.
>
>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.

Maybe "that wouldn't be NFS" but would such a derivative network
filesystem be all that difficult?

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.

// George


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