> >>> 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.
> >> First, I'd like to point out that (ideally) this list of pending entries
> >> will exist about a minute: right after the kernel is alive, and right
> >> before file-systems are mounted.
> >>
> >> Before I address the second paragraph about userland dameon upcalls, I
> >> have to know if you're referring to this addition specifically (the
> >> pending pathnames list), or the entire subsystem(s). If the former, see
> >> above; if the latter -- I'm afraid that (at least for now) that's out of
> >> the question.
> > 
> > the latter.
> 
> Let's leave this for yet another thread then.

why?  it removes the need of "pending entries" as well.

> > for your purpose, is it appropriate to associate pathnames to
> > a namespace of a process which loaded entries?
> 
> (yes, process 0. :)
> 
> I'm not sure. First you must understand that it's not always guaranteed
> that a process will be loading these pending entries: they may be loaded
> by the kernel itself, too.
> 
> The pathnames loaded are relevant to the entire system, not just a
> single process: one process may load Veriexec entries for the entire
> system, another may do the same for a different subsystem.

you mean it can't co-exist with per-process namespace?

it isn't clear to me how generic you consider the "pending entries" is.
is it merely a hidden communication channel between fingerprint loaders
and mount(2)?  if so, there is no point to implement it in kernel, IMO.

YAMAMOTO Takashi