Re: Question about setting watches in auto-mounted directories in RHEL 5.2
On Sun, Nov 30, 2008 at 10:47:07AM -0500, Steve Grubb wrote:
On Sunday 30 November 2008 10:11:10 Alexander Viro wrote:
> > > Unfortunately, auto-mounts are, well, automatic, so there's no one to
> > > issue that command.
>
> You do realize that they are, in the end, done from userland? ?Which is
> the natural place to do that...
The problem is that's a little racy. But more importantly, it would be nice to
load rules once since there is a chance that high security installations will
have the audit system in immutable mode.
For rules that do not resolve all the way to an inode, they could be put on a
wait list that gets checked for resolution anytime mount is called.
Races are not hard to deal with - you mount on temporary directory,
mark equivalent and mount --move to final destination. autofs daemon
could do that just fine.
As for the "anytime mount is called"... What are you going to do with
the rules that *do* resolve to destination (subtree ones)? And to deal
with the same races you'd have to do highly unpleasant things.
In principle, it is possible. We hold i_mutex on the mountpoint and there
is a moment just before grabbing vfsmount_lock when we know that we won't
be backing off. That's when we are about to make the changes visible and
locking conditions at that point are not quite unbearably bad.
They *are* quite bad, though. There are three parts of that fun:
* audit_filter_mutex needs to be held. Not a problem.
* ->inotify_mutex is taken inside ->i_mutex that way. Not
a problem, we already have that situation.
* the real bitch: we really, REALLY can not do pathname resolution
of any kind while we are in that area. kern_path() is a non-starter.
That's where the PITA starts. Initial part is simple - we already know
where and what we are going to attach, so unlike the case of MAKE_EQUIV
handling we do not need to bother resolving those pathnames. However,
the rest sucks hard enough to excavate decency from a politician.
We need to decide which rules to extend. And doing _that_ accurately
takes pathname resolution. Without it... well, the best proxy would
be to see which rules cover a counterpart of mountpoint in some mounted
instance of filesystem containing. Translation: we'll be getting false
positives until audit_trim_trees() could be run. And we *can't* run it
synchronously until we at least drop namespace_sem.