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