On Fri, Oct 14, 2016 at 11:28 AM, Marko Rauhamaa <marko.rauhamaa@xxxxxxxxxxxx> wrote: > Amir Goldstein <amir73il@xxxxxxxxx>: > >> On Thu, Oct 13, 2016 at 8:35 PM, Marko Rauhamaa >>> My employer certainly is in need of monitoring a whole filesystem. We >>> have noticed that namespaces evade monitoring via FAN_MARK_MOUNT. I >>> was thinking something like a FAN_MARK_FILESYSTEM would be needed. >> >> [...] >> >> I keep hearing about people that wanted that feature, but those people will >> need to come forward and voice their use cases. > > Well, F-Secure's Linux Security product monitors files to detect > malware. Files are analyzed for viruses and unexpected modifications to > system files are flagged. > This I could have guessed :-) Let me rephrse my question - please argue why monitoring a file system instead of a mount point is important for your use case and more impotantly, please argue why you cannot achive the same result by monitoring all the relevant mount points from user space. For example, the argument I used against the legacy recursive intotify watch of all directories in the treee is the poor ability to scale well over millions of directories. > > Other fanotify deficiencies include: > > * the offending process can die without leaving a trace because > FAN_CLOSE_WRITE events do not block (instead of blocking, it would be > enough for the /proc/$PID directory to stay available while the > related fanotify fd is open) > > * the (e)uid and (e)gid of the offending process are not conveyed in > the fanotify event > > * the FAN_OPEN_PERM event does not carry the mode so write access > cannot be denied > > * there is no (PERM or non-PERM) event generated by the first > modification (FAN_MODIFY generates a flurry of events; > FAN_CLOSE_WRITE does not get generated unless the file is closed) > > I am not sure I will be able help you wrt those extra requirements. Amir. -- 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
