Hi, On Thu, Sep 01, 2011 at 12:05 +0400, Cyrill Gorcunov wrote: > ... > > > +/* > > > + * NOTE: The getattr/setattr for both /proc/$pid/map_files and > > > + * /proc/$pid/fd seems to have share the code, so need to be > > > + * unified and code duplication eliminated! > > > > Why not do this now? > > There are a couple of reasons. Yesterday I was talking to > Vasiliy Kulikov about this snippet, so he seems about to send > you patches related to /proc/$pid/fd update, and after those > patches will be merged we are to drop code duplication. > Vasiliy, what the status of the update? It looks like protecting directories with sensible contents is a nasty thing. The problem here is that if the dentry is present in the cache, ->lookup() is not called at all and the permissions can be checked in fop/dop/iop specific handler (getattr(), readlink(), etc.). However, it would be much simplier to hook ->lookup() only. Otherwise, we have to define procfs handlers for all operations, which don't call ->d_revalidate(). Is it possible to disable caching dentry for specific files? It is not performace critical thing in fd and map_files and it would much simplify the task. Creating handlers for all these op handler bloats procfs. Also I'm not sure what other handlers might reveal dentry presence. Besides ->getattr() I could find only one thing - ->link() (Cyrill, AFAICS ->setattr() doesn't reveal files' presence). Someone more familiar with vfs than me - please, help to identify all infoleak sources! Thank you, -- 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
