Subject: Re: improving kqueue
To: Matthew Mondor <mm_lists@pulsar-zone.net>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 02/23/2007 13:47:29
--MW5yreqqjyrRcusr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Feb 23, 2007 at 04:20:21PM -0500, Matthew Mondor wrote:
>=20
> Continueing quite an old thread now that I had a little time to install
> -current and check the reference documentation (svr4) about adding the
> possibility to be notified about vnode modifications events for a whole
> tree rather than a single vnode via kevent:
>=20
> If I understand, Bill's reference to svr4 book (the design of the unix
> operating system from Bach), was to point out that it is possible to
> lazily mark vnodes as "is being watched" at lookup time if it is under a
> watched parent vnode. This would seem to easily allow to return a knote
> with the event type/file handle information back to userland, say for a
> new EVFILT_VNODE_TREE or such filter type.
>=20
> This being all fine, there are other problems, however:
>=20
> - The functionality would need to be restricted to the superuser,
> considering that file handles bypass permissions (mentionned in
> fhopen(2) man page)
Depends on what we pass back. If we pass back a file handle, then yes, we=
=20
need to restrict to superuser.
> - A file handler needs to be resolved back to a pathname for userland.
> There doesn't seem to be a syscall to perform this, nor a reverse cache
> in the kernel currently (probably because of the kernel memory wastage
> this would imply)
However if we pass back a path, then we don't need to restrict the return.=
=20
We just require an access check on the to-be-returned path before return.=
=20
If you can see it, then we can return it.
I think we will need to figure out how to handle reverse paths. There are=
=20
more and more things going on (well, not yet in NetBSD :-( ) where reverse=
=20
paths will be really useful/needed.
> - Moreover, a vnode may resolve to multiple path names, because of
> possible hard links
Or 0, an der Mouse noted. Oh well. For this type of thing, if you can't=20
get a path, chances are the event won't do you much good.
> Does this imply that the userland daemon would need to perform the follow=
ing:
>=20
> - Setup a kqueue filter on the wanted parent vnode (requested directory)
> - Recursively scan the parent direcory using getfh(2) and build a hash
> table or btree allowing duplicate targets (with unique fh keys)
> (as well as using fhstat(2) and cache permissions, optionally)
> - Verify for any meanwhile queued kevents and adapt cache (changes may
> have occurred during the recursive cacheing process).
You can key all of it off of inode #. While it is questionable to build a=
=20
file handle from an inode #, if you have an fh and get the inode, chances=
=20
are that all file systems will always return the same inode # for the same=
=20
file for its life. So you need only index on a 64-bit # as opposed to=20
arb-len file handles. :-)
> If such a daemon was to accept client connections via a library, it
> would need to use ancilary data to determine the actual user
> credentials, and to ensure to only report events (converted to paths)
> for files which can normally be accessed by that user (either using
> access(2) (which would mean that for each client the daemon would
> probably need to spawn a new process and revoke its privileges to that
> of the user) or perform a userland brewed equivalent check using
> pre-cached permissions).
Yes, if we do path construction in userland.
> I'm unsure yet of how large the cache would be for general use (although
> it would be easy to write a small program to test this on various paths,
> to determine cost of building the cache, performing lookups and
> determining the size of that cache for various paths).
>=20
> If the system was to only be used by modules running as the superuser,
> access checks would probably not be necessary and dlopen could be used
> to load them; A function of the module could be called to propagate
> events to them or such.
>=20
> I would be interested to know more about the particular project(s) this
> feature was requested for. For a fam daemon replacement, the
> permissions checking would seem unavoidable, IMO.
>=20
> It would also be great to hear other's ideas about how this could be
> done more effectively...
Take care,
Bill
--MW5yreqqjyrRcusr
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
iD8DBQFF32DxWz+3JHUci9cRAo6YAJ4uqZW0NiJnKxkbIhIVImRLKJETkgCfUJ0f
7RJIb9Dq1IDwvQeJu+hJtoQ=
=6JHC
-----END PGP SIGNATURE-----
--MW5yreqqjyrRcusr--