On Tuesday 04 August 2009 17:27:48 Eric Paris wrote: > On Tue, 2009-08-04 at 17:09 +0100, Tvrtko Ursulin wrote: > > Hi Eric, all, > > > > On Friday 24 July 2009 21:13:49 Eric Paris wrote: > > > If a FAN_ACCESS_PERM or FAN_OPEN_PERM event is received the listener > > > must send a response before the 5 second timeout. If no response is > > > sent before the 5 second timeout the original operation is allowed. If > > > this happens too many times (10 in a row) the fanotify group is evicted > > > from the kernel and will not get any new events. Sending a response is > > > > Would it make more sense to deny on timeouts and then evict? I am > > thinking it would be more secure with no significant drawbacks. Also for > > usages like HSM allowing it without data being in place might present > > wrong content to the user. > > I'd be willing to go that route as long as noone else complains. Ok, keep it open then for a while and I guess it is trivial to change this bit of behaviour. > > > The only other current interface is the ability to ignore events by > > > superblock magic number. This makes it easy to ignore all events > > > in /proc which can be difficult to accomplish firing FANOTIFY_SET_MARK > > > with ignored_masks over and over as processes are created and > > > destroyed. > > > > Just to double-check, that would also work for any other filesystem and > > is controllable from userspace? > > Yes you set these in userspace using setsockopt(). It is based on > superblock magic number as found in linux/magic.h. So one could > exclude, procfs, sysfs, selinuxfs, etc. It does not provide a way to > say 'this ext3 filesystem but not that ext3 filesystem' as ext3 has a > single magic number. This is probably good enough. Subtree and mount point exclusions would be even better (in addition to superblock magic exclusions - I would not get rid of them) but I have no idea how realistic this requirement is, or whether it is possible to do it more efficiently in kernel space at all. Tvrtko -- 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
