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. 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...

> 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.

One use of it is Veriexec, because that's something we already have in
the tree. Admittedly, though, the motivation is doing it for something
else.

To better understand what the purpose of the pending entries, let's take
a look at something more familiar: Unix permission bits. These are
embedded in the on-disk inode, and the file-system code understands
them, so a scenario where there's a race between mounting a file-system
and having the kernel aware of the permission bits is impossible.

Fileassoc(9) provides a way to attach meta-data to files, in some ways
similar to what extended attributes would provide, in others not so (the
data is not on-disk and not persistent). So for any data that we're
interested in attaching to a file by using fileassoc(9), we first have
to wait for that file to "exist" (or, for the file-system it's on to be
mounted), and then the kernel will be able to lookup the vnode for the
file and use it in calls to the KPI.

What I'm interested in achieving with pending entries is the ability to
minimize this gap between the time the file-system is mounted and the
time fileassoc(9) entries for the files on it are loaded.

For example, let's say at some point we introduce capabilities to the
system, and use a scheme similar to /etc/signatures to store the mapping
between program and capabilities (either because we lack file-system
extended attributes, because we didn't modify the program to use some
ppriv(3)-like API, or because the program in question is closed source).

Any program (or daemon) ran before the we load the capabilities database
to the kernel will not be "capabilities aware". To avoid that, we'll
have to load the mapping as early as possible in the boot process --
maybe even before the file-system with the program in question was
mounted.

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".

While adding file-system attributes will solve a lot of this, I
personally would like to get this feature in for fileassoc(9) as well,
as I think it may come in very useful.

-e.