Subject: Re: Pending entries support for fileassoc(9)
To: None <elad@NetBSD.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 12/11/2007 19:33:38
> >>> 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.