ev_stat inotify implementation might miss events

Marc Lehmann schmorp at schmorp.de
Tue Jan 26 18:41:57 CET 2010


On Tue, Jan 26, 2010 at 05:05:41PM +0100, Yoann Vandoorselaere <yoann.v at prelude-ids.com> wrote:
> > That is impossible unless you make everything synchronous, so inotify
> > cannot guarantee it.
> 
> Again, as I understand it, Inotify events are generated at syscall
> levels, so they are synchronous to a syscall.

Again, your understanding is flawed - that would be a security bug :)

> >From the Inotify manpage:
> 
> "If successive output inotify events produced on the inotify file
> descriptor are identical (same wd, mask, cookie, and name) then they are
> coalesced into a single event if the older event has not yet
> been read (but see BUGS)."

Yes.

> For the record, the Linux auditing subsystem rely on Inotify.

Yeah, and it doesn't work for auditing, which is why security companies
want a synchronous system.

You can look this stuff up.

> If inotify already reported the event, I don't think it will update the
> WD associated with it. Theses event are already stored in the userspace
> buffer declared by libev, and you cannot expect the Kernel to update the
> WD associated with event that you have already read().

That would be a kernel bug - when I ask the kernel to give me events for a
specific path, and it doesn't give me them, that's a bug in the kernel.

> infy_cb() loop through the events, and call infy_wd(), which will
> sucessfuly lookup the first event. However, since libev registered WD is
> changed at this point, the second iteration of infy_wd() won't find the
> correct ev_stat handler.

That's fine, because libev is interested only in events that arrive after
the ev_stat_stat call. If your kernel doesn't deliver them, it is buggy.

> It would be interesting for libev to provide the ability to keep
> monitoring the file until no application reference it anymore
> (st_nlink).

I don't have any interest in making libev a linux-only library, sorry.

If you want that, you cna use inotify, it's not that hard to use.

Libev needs to stay portable.

> If the file has been deleted but is still referenced by others
> applications, then continue monitoring it, and open a new ev_stat()
> handler in case any application re-create the filesystem file.

That behaviour would be a bug in libev.

If you want inotify behaviour, you have to use inotify. ev_stat watchers
do what they do because that behaviour is portable.

What you describe will not help ev_stat in any way - was that what you had in
mind (make libev linux-only) or do you have a real idea on how to improve it?

(Obvious improvements would be to avoid rearming if the file wasn't
renamed, but that's just an optimisation).

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list