Andreas Dilger wrote: > On Jul 25, 2009 01:29 +0100, Jamie Lokier wrote: > > Eric Paris wrote: > > > But maybe I should jsut do the 'if you have fanotify open, you don't > > > create other fanotify events'... so everyone gets what they expect... > > > > O_NONOTIFY. Similar security concerns, more control. > > > > The security concern is clear: If you allow a process with fanotify > > open to not create events, then any (root) process can open a fanotify > > socket to hide it's behaviour. > > I think the "fanotify doesn't generate more fanotify events" makes the > most sense. Given that the open will be done in the kernel specifically > due to fanotify, this doesn't actually allow the listener to open files > without detection (unlike the "O_NONOTIFY" flag would). The fanotify > "opens" would only be in response to other processes opening the file. Nice idea (if I understand it) - the file descriptors opened by fanotify wouldn't cause fanotify events? Effectively having an in-kernel O_NONOTIFY flag which can't be set from userspace? 'if you have fanotify open, you don't create other fanotify events' is too severe - it means you can circumvent fanotify entirely for everything your process does by just opening a fanotify socket and not using it, which is clearly worse than having an O_NONOTIFY flag. All ways to avoid creating fanotify events introduce security and cache integrity problems though. Why should processes which simply _watch_ the filesystem, without modifying any files, ever fail to receive information about file changes? Why should they be unable to claim they provide integrity guarantees because of the loophole? So before we implement that loophole: let's ask ourselves if we really need it at all. What's wrong with fanotify-using applications generating events when they modify files themselves? An example was given where app A gets an event and modifies the file, then app B gets an event and modifies the file, and app A... cycling. But if you have two "virus checker" style applications fighting over modifying the same file without locking, you have much bigger problems already. There's nothing to gain by fixing the fanotify cycle. Maybe there's no need to suppress events after all. Programs monitoring for writes to maintain caches or integrity checks will be much happier if they know they're getting all file modifications. -- Jamie -- 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
