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. The cache is implemented as inode ignored mark. I suppose there could be a race here. Consider the following scenario with hostile processes A and B, and victim process C: 1. Process A opens new file for writing. File check request is generated. 2. File check is performed in userspace. Check result is "file has no malware". 3. The "permit" response is delivered to kernel space. 4. File ignored mark set. 5. Process A writes dummy bytes to the file. File ignored flags are cleared. 6. Process B opens the same file for reading. File check request is generated. 7. File check is performed in userspace. Check result is "file has no malware". 8. Process A writes malware bytes to the file. There is no cached response yet. 9. The "permit" response is delivered to kernel space and is cached in fanotify. 10. File ignored mark set. 11. Now any process C will be permitted to open the malware file. There is a race between steps 8 and 10. The race could be easily reproduced by Andreas's fanotify example: console1# ./fanotify -s1 -o open_perm,modify,close -m /mnt console2# while :; do echo 123 >> /mnt/123.txt; done echo command opens, then writes, so write should clean ignore mask and every open call should be intercepted but actually only every 2-nd call is intercepted. 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. 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. 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. 4. FAN_DENY response has no effect at the moment. Regards, Vasily -- 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
