--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=
=20
> >with each export. Something that is stable across boots. 2) add space in=
=20
> >the file handle to indicate which export point a file handle came from,=
=20
> >and 3) add some sort of authentication so that we can tell if it's likel=
y=20
> >the file handle has not been tampered with. The thought is to do somethi=
ng=20
> >so that it's harder to forge file handles.
>=20
>=20
> 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=20
different exports from the same server file system behave as if they are=20
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=20
performance impact. As Jason mentioned, the main idea here is that instead=
=20
of having "mount" info in the file handle, we have some form of "export"=20
info. It'd mean a changed multiplexing/demultiplexing, but it wouldn't be=
=20
hard to do.

Take care,

Bill

--YZ5djTAD1cGYuMQK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFvugTWz+3JHUci9cRApexAJ9aLon9z1q91pdXSw7BmDbiWAEqHACcCGZe
CWu6A6bEj9OBqlhf0wFDbA4=
=rYBv
-----END PGP SIGNATURE-----

--YZ5djTAD1cGYuMQK--