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

On Wed, Oct 19, 2005 at 01:14:56AM +0200, Gerhard Sittig wrote:
> On Tue, Oct 18, 2005 at 14:02 -0700, Bill Studenmund wrote:
> >=20
> > Unfortunately inode numbers aren't exposed to userland. However, they c=
ome
> > conveniently bundled (with generation numbers) in file handles. And tha=
nks
> > to my dmfs work, file handles ARE readily exposable to userland. :-)
> >=20
> > In your VFS layer, when you have a node you want to ask about, all you=
=20
> > have to do is call VFS_VPTOFH() and you'll have the file system-specifi=
c=20
> > part of the file handle. Add the 16-bits of mount-point specific info=
=20
> > NetBSD adds, and you have the file handle.
>=20
> So this kind of handle (internal fh representation derived from the
> vnode) is NetBSD specific?

Oh no. Anything that supports NFS has file handles somewhere. They are how=
=20
NFS identifies files. On the client, the VFS layer maintains a 1:1 mapping=
=20
between vnodes it has and the file handle used to talk to the server for=20
that vnode.

The exact layout of a file handle is OS specific, though we and FreeBSD,=20
Dragonfly, and OpenBSD probably generate the exact same ones for a given=20
inode # and generation #. They are also endian-dependent (a big-endian=20
machine will generate a different file handle than a little-endian machine=
=20
given the same file system).

> The nice thing about Dazuko is that it has an identical API across all
> supported platforms.  It currently runs on UNIX versions only, but in
> theory can support completely different platforms like DOS or Windows.
> The platform specific parts are well layered and hidden from the API
> user.

Well, that's nice and all, but as you noted in the original EMail, they=20
are doing things that are no-nos. :-) So the API probably should change at=
=20
some point. :-)

> But again you suggest a possible solution below.
>=20
> > If userland needs to adjust the file any (needed for tertiary storage, =
not=20
> > necessarily for what you're doing), fhopen() can let root open the file=
=20
> > w/o knowing the path name (yes, that's why only root can do it).
>=20
> For filename based rule set checkers the filename would be useful.  For
> content filters the filename is not of too much concern, the file's
> content is of interest and can be accessed with the fh determined above.
>=20
> This would mean that loggers are out of luck here, scanners could
> continue to work.

[snip]

> When a userland daemon accesses files with open(2)/fopen(3), this can be
> any regular file or the pseudo filename previously gotten from the VFS
> layer as the handle for the vnode the access is to be checked for.  This
> means that the open(2) syscall (or the appropriate lookup and open vops)
> need to be hooked.  To remap pseudo filenames to internal file handles.
>=20
> I have to think about this for some time and see how to best solve this
> problem.  It looks like the VFS layer has to
> - intercept the create, open, close, unlink, rmdir, rename vops to catch
>   these file accesses, get the fh for the vnode and pass the event up
>   with the fh encoded in a pseudo filename
> - hook the lookup vop to catch accesses to the pseudo filenames, remap
>   those pseudo filenames to their internal fh or use the original lookup
>   method for regular path names

If you wanted to go the pseudo filename route, you could make a fake=20
directory in the root (hooking into VOP_LOOKUP(). For any lookup in that=20
directory, you just do an unmapping of hex-dump-file-handle, and call=20
VFS_FHTOVP() on your mount point.

> This sounds like I could implement it in the next weeks and see how well
> this works (and how bad it is that loggers won't be too useful, only
> scanners work without noticing too much of this internal change).  Then
> I need to get the code reviewed to get vnode locking right.
>=20
>=20
> Thank you very much for your telling me what's wrong with my initial
> vn_fullpath() request and offering a reliable way to address a vnode
> from the "filenames namespace". :)

No problem.

Take care,

Bill

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

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

iD8DBQFDVpKTWz+3JHUci9cRAu1ZAJkBKRkWmsmugBaRaA8tMuDrYlSpkgCcCykC
pxS7GX/GMBSP/jVH/X08DT0=
=DQgA
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--