On Mon, Sep 05, 2011 at 23:20 +0400, Cyrill Gorcunov wrote:
> On Mon, Sep 05, 2011 at 10:53:58PM +0400, Vasiliy Kulikov wrote:
> ...
> >
> > +static int pid_no_revalidate(struct dentry *dentry, struct nameidata *nd)
> > +{
> > + if (nd && nd->flags & LOOKUP_RCU)
> > + return -ECHILD;
> > +
> > + d_drop(dentry);
> > + return 0;
> > +}
> > +
>
> Thanks Vasiliy! So every lookup will cause dcache to drop previous cached
> entry and alloc and hash new one instead, pretty dramatic, espec in case
> of huge number of files mapped ;) Still since it's not time critical operation
> (at least for now) I tend to agree.
Actually, it can be speed up by introducing the same ptrace check. If
ptrace check fails, then just drop the dentry, otherwise continue to use
it. Then each revalidate would trigger ptrace check instead of full
drop-lookup-alloc cycle. If one process actively looks into
map_files/ or fd/, it will not become significantly slower. However, it
will trigger 2 capable() fail alerts in ptrace_may_access() instead of
one :)
But I still see one very nasty issue - one may trigger this ptrace check,
trigger d_drop() and then look at /proc/slabinfo at "dentry" row. If
the number has changed, then the interested dentry existed before the
revalidate call. This infoleak is tricky to fix without any race.
Probably it's time to close /proc/slabinfo infoleak?
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
