On Mon, Sep 05, 2011 at 11:49:08PM +0400, Vasiliy Kulikov wrote: ... > > 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 :) Hmm, at least it's better than trashing dcache I think. > > 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? > Actually I miss to see how exactly this infoleak can be used by attacker or whoever. So, Vasiliy, what the security issue there? Cyrill -- 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
