Subject: Re: Pending entries support for fileassoc(9)
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Elad Efrat <email@example.com>
Date: 12/05/2007 12:58:15
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
> 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
> 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. :)