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

On Sat, Jun 17, 2006 at 09:02:53PM +0930, Brett Lymn wrote:
> On Thu, Jun 15, 2006 at 11:08:20AM -0700, Bill Studenmund wrote:
> >=20
> > You also are using identifiers (dev_t and inode_t) that really shouldn'=
t=20
> > be used outside of the file system. We have cleaned-up abstraction=20
> > structures (file handles, for example) that remove much of the problem=
=20
> > wiht what you're doing. Their existence predates my use of NetBSD, and=
=20
> > actually they predate NetBSD. Yet you aren't using them.
>=20
> The blame for the usage of dev_t and inode_t can be laid at my feet.
> When I started working on veriexec I looked for something that would
> uniquely identify the file and found the va_fileid and va_fsid
> elements in struct vattr.  Though they may be referenced as dev_t and
> inode_t in the veriexec code they really are not used as anything
> apart from tags to uniquely identify a file on a file system.  These
> values are taken from the results of a VOP_GETATTR() call and are only
> compared with results of other VOP_GETATTR() calls.  So, though the
> numbers may have meanings in other contexts, in the context of
> veriexec they are just a tuple of numbers to identify the file.
> Unless I am mistaken, I believe that the metahook code is treating
> dev_t and inode_t in the same manner - just as unique tags.

Well there are issues. One is that unionfs doesn't use them right; you=20
just get the inode number from the underlying file, be it the upper or=20
lower. :-( So two files can return the same inode number.

> > Plus, generation numbers are important, even for local disk stores. Sin=
ce=20
> > you aren't storing pointers to the vnodes, use file handles.
>=20
> Any hints on using file handles?  I had a quick look around an the
> only thing I could see was fhopen() and friends who use VOP_VPTOFH().
> According to the man page for VOP_VPTOFH() it only works on NFS
> exportable file systems.  Won't this preclude some file systems?
> Including NFS? (since NFS mounts cannot be re-exported, indeed the
> nfs_vptofh() and nfs_fhtovp() calls return EINVAL).

We probably should fix this for NFS. The calls are TRIVIAL. The one issue=
=20
might be that our file handles may not hold the other system's file=20
handle, but things will at least work for some systems.

While you shouldn't export NFS client mounts, I don't think VFS_VPTOFS()=20
is the place to force that.

Actually, the man page I have for VFS_VPTOFH doesn't restrict it to NFS=20
exports. I think the constraint is that NFS-exportable file systems MUST=20
support FH<->VP operations, but that other, non exportable, file systems=20
may also support them.

The biggest issue I see with file handles is that they are variable=20
length. For the hashing Elad had in mind, that's not a big deal. For=20
storage, it might be. I'm not sure what the best way to approach this is.

Take care,

Bill

--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFEltKUWz+3JHUci9cRAqxlAJ9SxMOFe1jiE3nsUlGMn/O7eSXK0QCfbHxQ
49phupDkdvSG8C9yypD5L3U=
=Zn5u
-----END PGP SIGNATURE-----

--jI8keyz6grp/JLjh--