On Thu, 2009-08-06 at 13:23 +0200, Peter Zijlstra wrote: > But yes, if its so invasive to the filesystem as to make it unusable I'd > argue it to be part of the filesystem, we do filesystem encryption in > the filesystem, so why should we do such invasive scanning outside of > it? In kernel? yes. In filesystem? No. This isn't fileystem specific, it's system wide. Didn't we have the discussion about fuse not being as all encompassing as a number of people wanted? Think nfsd. Dazuko is I believe working on generic stackable filesystems which might eventually be able to implement a better set of hooks, but that is a LONG way from a solved problem last I heard. > > We are taking about the kind of fanotify client that says: No you cannot > open/read/write/mmap/etc.. this file until I say you can, right? Only open and read (or first mmap for read). Nothing available for write. Noone purports this to be an LSM. > By the above you're hosed anyway since starting a new one will fail due > to there being no daemon, right? Might as well forfeit all security > measures once the daemon dies. That is let security depend on there > being a daemon connected. Nope. You should stop calling and thinking of it as a security system. As I've said multiple times it is at best an indexing and integrity checking system. We fail open. We don't prevent or care about malicious local attacks. When a group is evicted everything is going to just work. The whole reason for the timeout is because I don't trust userspace not to get it wrong and I'd rather not lose my box because of it. Yes, the reset I'm proposing allows userspace to screw the system forever, but at least that is an active operation, not an accidental segfault bringing down the whole system. > Seems like a weird thing to me, suppose you DoS the system on purpose > and all clients start getting wonky, you kill them all, and are left > with non, then you cannot access any of your files anymore and > everything grinds to a halt? Nope, you DoS the system on purpose all the listeners get evicted, now everything else will be able to open/read data without those listeners paying attention. When a group is evicted it's evicted. It no longer needs to say yes or no. > Like said, having the filesystem block actions based on external > processes seems just asking for trouble. Or it seems like exactly what hierarchical storage management systems want.... -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
