Messages in this thread | | | Subject | Re: fanotify - overall design before I start sending patches | From | Eric Paris <> | Date | Thu, 06 Aug 2009 14:18:10 -0400 |
| |
On Thu, 2009-08-06 at 13:58 +0100, Alan Cox wrote: > > > 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? > > > > Yes and no, it would be more accurate to say "this open takes long while we do > > something else in the background". > > There are two or three ways to handle this > > 1. Block the open until the daemon dies or responds > 2. Have a timeout (which would need to be connection configurable) > 3. Require the daemon responds with "in progress" now and then.
I've taken option #3. I don't see options #2 as viable, although off list discussion from clamav people has said they believe they are interested in #2 rather than #3.
> For a superuser managed service its no different to an NFS mount which > can go wonky so the only real question is what should fanotify allow non > privileged users to do. The answer would appear anyway to be: not use > this aspect of such a facility.
That's the approach taken thus far. Although non-blocking/access notification will be opened up to normal users (currently even notification is root only)
> For the superuser case the fact the daemon can be killed thus releasing > anything stuff is analogous to umount -f of a stuck NFS mount which seems > perfectly good for NFS.
It does work for NFS (which I would call case #1.) I claim that it doesn't work for this case since a global listener stuck would stop you from running kill() since it owuldn't be able to get permission to open it....
| |