On Sat, 2009-07-25 at 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. Let me first say I'm not sure of how many useful 'security' goals can be met using fanotify mainly because I haven't focused on any. You can do data integrity checking before access but I'm saying up front, malicious programs can almost certainly sneak information across these checks. The 'problem' is really strongly with the open and open_perm, but there are problems with read_perm as well. With just 2 groups listening to 'open' for the same file we get that infinite event loop as they each see the open from the other listener as each listener opens an fd on the object in question. If both groups are listening to open_perm you obviously have a deadlock.... The same applies if 2 fanotify groups need read_perm as they both may need to block waiting for the decision of the other. I have an easy solution to the 'open' problems, just don't fire the open and open_perm events when it is fanotify doing the open. I guess I could use file->private_data when the fanotify listener does io on an fanotify opened file to see if it was an fanotify opened fd and ignore only those events.... I'll try this afternoon. So really now I'm planning to only not send events to other fanotify listeners which are on fanotify opened fds. > Do I see right that you need to open the directory before you can set > the mark on it? Correct. But unlike dnotify, you don't have to keep it open. > The main reason behind inotify's design wasn't the API (although it is > better than dnotify); it was to avoid having to open thousands of > directories, and to allow a filesystem to be unmounted while it is > being watched. I could make fanotify_so_mark pathname rather than fd based. But fd based works very nicely in global mode as the fd you get in the event metadata can be used in setting marks. You need to open the directory so you have an fd, so you can set the mark. You can then close the directory. If the directory is deleted, your mark is gone (forever.) > Does a fanotify mark stop a filesystem from being unmounted? If not, > if the filesystem is unmounted and remounted, is the mark lost? No, it does not prevent unmounting. Yes, if it is unmounted and remounted the marks are lost forever. -Eric -- 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
