[trimming the CC list because it looked really funky on my end] Hi Vasily, On Tuesday 26 Oct 2010 13:13:15 Vasily Novikov wrote: > Hi Eric, > > We are interested in using fanotify in anti-malware applications. I > found a few concerns in fanotify implementation from the recently > released 2.6.36 kernel: > > 1. Race in cache implementation. [snip] > I be believe it could be solved by introducing two more ignore mark > flags. The fist one to set before the scan starts. It could be cleaned > by write operation. The second one to ask fanotify to set ignore flags > only if the first flag is still set. In this case we will never have > file with not scanned file changes in cache. Interesting that you have also found this - I suspected it but did not actually got round verifying it. Another possible (and simpler) solution is to refuse (ignore) adding ignore marks if file (well inode) is opened for writing (inode->i_writecount > 0)? More or less this is the approach we use in Talpa. > 2. As I understood it was intended to flush cache via FAN_MARK_FLUSH > flag but it is currently disabled and there is no notion about it in the > man page. There are cases when it is necessary to flush all cache, for > example on anti-malware bases update. Where do you see this as disabled? > 3. I read the discussion about how to define paths to scan but anyway. > We would prefer to have global listener that was defined in the first > version of the interface and mark unnecessary mount points with > persistent ignore flags. Yeah, but according to Eric there was fierce opposition against global mode and hence he dropped it. I personally think anti-global mode arguments are not that solid but what can you do. I am pursuing another path of trying to add support for mount marks which automatically propagate to sub-mounts. That way you can mark root with a mount mark and when a new filesystem appears under it it will automatically inherit that mark. I have a proof of concept patch which works but needs some refactoring to comply with fanotify locking rules. Hopefully it will be possible to do it in which case I will post it for review. > 4. FAN_DENY response has no effect at the moment. I posted a patch for this some time ago (check the archive for September 7th). It wasn't 100% correct because of my misunderstanding of how mark merging works so I believe Eric will fix that properly in the next release. Tvrtko Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 348 3873 20. -- 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
