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

On Fri, Jan 26, 2007 at 02:53:42PM -0500, rick@snowhite.cis.uoguelph.ca wro=
te:
> >On Fri, Jan 26, 2007 at 06:46:36AM -0500, Thor Lancelot Simon wrote:
> >>On Thu, Jan 25, 2007 at 09:07:27PM +0100, Pavel Cahyna wrote:
> >>>=20
> >>> Could nullfs encrypt the filehandles of the underlying filesystem and=
 use
> >>> those encrypted filehandles for NFS?
> >>
> >>What should actually happen is what e.g. Solaris does: the filehandle
> >>given to the client should *always* be generated from the exported
> >>directory and underlying filesystem specific data, rather than the
> >>underlying data alone.  This would allow export of arbitrary directories
> >>with different permissions.
> >>
> If I understand what you are suggesting, it can result in multiple file
> handles/file when there are multiple hard links to a file. Although this

No. File handles within an fs will still be used in the same way. We will=
=20
just have a different mapping between the file system specific info and=20
the on-wire NFS file handle.

> seems to be permitted for NFSv3 and NFSv4.0, it causes problems for clien=
ts.
> (See a recent thread titled "RE: Finding Hardlinks" in the email archive
>  at www.nfsv4.org.) They are going to try and "fix" the problem for NFSv4=
.1.
>=20
> If you avoid having multiple handles/file, you can encrypt the filehandle,
> but that still doesn't provide a lot of security, since a "bad guy" can
> simply replay the filehandle. Since filehandles are T stable (ie. valid f=
or
> a very long time), they can't be expired and so replay becomes a no brain=
er.

True, but that's not the threat model we're worried about. We're worried=20
about file handles being used via a mount point other than the one that=20
reported it to the client.

Take care,

Bill

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

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

iD8DBQFFutaTWz+3JHUci9cRAmS5AJ4hQlzmf7D0wFLDV9wpFN5FKa/66QCgjsst
HxFPnRU8/t9zbL3Wn4Aydoc=
=Vjhd
-----END PGP SIGNATURE-----

--mvpLiMfbWzRoNl4x--