> YAMAMOTO Takashi wrote:
> 
> > can you explain what's wrong with loading fingerprints after mount?
> 
> Sure. :)
> 
> The above example I gave focuses on Veriexec, so let me "zoom out" a bit
> and elaborate.
> 
> Some subsystems, part of which are not (yet) present in NetBSD, require
> that interaction with various objects in the system be done with respect
> to meta-data associated with them. While fileassoc(9) at the moment
> allows associating meta-data with file-system objects, it only allows
> doing so once the object "exists". One drawback to that is that there's
> a window between the time the object is introduced to the system (say,
> mount) and the time the meta-data for the object is loaded.

your patch doesn't seem to remove the window.

> One example where this applies is Veriexec. Currently, a significant
> portion of the boot process happens before Veriexec entries are loaded.
> Allowing entries to be loaded before the files they're associated with
> "exist" allows us to better protect the system during boot: the veriexec
> rc.d script can be moved to the top of the rc list, and -- depending on
> how critical the environment is -- you could even embed entries in the
> kernel itself for /sbin/init et al.

protect from what?

> Other uses may be to associate, for example, integrity levels for
> file-system objects, such that a security model can properly enforce its
> policy on them.

this example is too vague for me to understand. :)

> Does that answer your question?
> 
> -e.

i think fileassoc has scalability problems, and this 'pending' thing
will make it worse.
how about making fileassoc (or veriexec, or whatever) issue upcalls
to userland daemon?  ie. keep databases in userland and consider
in-kernel entries as cache.
(btw, i want to do something similar for nfsd export table.)

for long term i'd like to make filesystem namespace per-process.
so, in general, i don't like the idea to keep pathnames in kernel without
associating them to a process.

YAMAMOTO Takashi