> YAMAMOTO Takashi wrote:
> >>>>> 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.
> 
> I don't see how having the entry database in userland and communicating
> it to the kernel removes the need for pending entries.

because you can use the same mechanism for mounted filesystem and
unmounted filesystems.

> The former is a
> Veriexec-specific design decision, the latter is an extension to a KPI.
> 
> It's likely that I didn't explain clearly what I want to achieve, so
> see below:
> 
> >>> 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?
> 
> I don't mean it can't co-exist with per-process namespace, I mean that I
> don't see how the two are related...

for example,
1. process A loads pending entries.
2. process B, which doesn't share namespace with process A, mounts
  a file system.  pending entries loaded by process A are meaningless here.

> > 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.
> 
> First, it's not a hidden channel between fingerprint loaders and
> mount(2). It's a way to introduce entries in fileassoc(9) -- that works
> on the VFS layer -- before the files these entries are for exist on the
> system.

your pending-entries-loader needs to know where file systems will
be mounted.  loaded entries will be consumed only by mount.
i don't see how it isn't a communication channel between the loader
and mount.

> Hence, the need for pending entries in fileassoc(9): a temporary list
> saying "we want to attach this meta-data to these files as soon as
> they're introduced to the system".

what's wrong with simply loading them immediately after mount?

YAMAMOTO Takashi