YAMAMOTO Takashi wrote:

> your patch doesn't seem to remove the window.

Are you referring to the lack of locking on the mount itself, in a way
that allows performing operations on the mount-point right after it was
mounted and before the traversal on the pending list was done? please
elaborate.

> protect from what?

In the Veriexec case, to protect from running a program if its signature
does not match the one in the kernel.

>> Other uses may be to associate, for example, integrity levels for
>> file-system objects, such that a security model can properly enforce its
>> policy on them.
> 
> this example is too vague for me to understand. :)

There will be another thread for this one. :)

> i think fileassoc has scalability problems, and this 'pending' thing
> will make it worse.
 >
> 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.

> for long term i'd like to make filesystem namespace per-process.
> so, in general, i don't like the idea to keep pathnames in kernel without
> associating them to a process.

Nothing is set in stone, introducing functionality now only means we'll
have to adapt it to a new reality in the future. While I am interested
in this, I'd like to hear about it in a different thread. :)

-e.