ev_stat inotify implementation might miss events

Marc Lehmann schmorp at schmorp.de
Tue Jan 26 21:36:50 CET 2010

On Tue, Jan 26, 2010 at 07:53:18PM +0100, Yoann Vandoorselaere <yoann.v at prelude-ids.com> wrote:
> > Again, your understanding is flawed - that would be a security bug :)
> After looking at Linux kernel 2.6.32 kernel code, I can confirm that my
> understanding is not flawed. 

it is :/

> I guess you then need to explain why this is a security bug ;)
> static inline void fsnotify_modify(struct dentry *dentry)

I told you you are confusing fsnotify with inotify.

fsnotify gives you an event for each change, and is synchronous. inotify
does not and is asynchronous. fsnotify is usable for auditing, inotify much
less so. fsnotify requires privileges, inotify does not.

> Google Source search is your friend

Yes, but it doesn't interpret results for you.

> > 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.
> It does. The problem is that libev read a pile of Inotify events, but
> every events in the pile, except the first one will get ignored.

I have no clue what you are talking about, this is simply not what libev

When it registers an inotify watcher for a file, it expects to get events for
this file _after_ it has registered.

And this is what happens.

Your problem is that you fail to understand inotify - it simply cnanot
give you one event for each change, this is impossible without it becoming
synchronous, introducing a security bug.

> > Libev needs to stay portable.
> The behavior described in my previous mail can be emulated with stat(),
> and is fully portable, as per POSIX specification:

Grr. Claims, claims, claims, all wrong.

> "Unless otherwise specified, the structure members st_mode, st_ino,

Point being? How do I magically find the new name of the file?

> For the record, Prelude-LML used to do it before using libev. And it has
> been working on much of the architecture available out there.

Do to what? ev_stat watchers with inotify? On other architectures than linux?
Wow, impressive.

Look, you keep spilling out outright bullshit, you confuse fsnotify and
inotify even AFTER being told about it, you make obviously flawed claims
about libev and inotify, and frankly, my patience for people spilling
bullshot AFTER it being explained to them is zero nowdays.

Come with facts, or shut up.

> > (Obvious improvements would be to avoid rearming if the file wasn't
> > renamed, but that's just an optimisation).
> The improvement I am talking about consist of moving the decision into
> the application hands. There is no loss of functionality. I could also
> argue that automatically rearming a file whose st_nlink is higher than 0
> can be considered as a bug.

You can argue like that, but only if you are an idiot who hasn't understood
the documentation.

So please do us a favour and explain how this would be bug?

Pity, you can't, because this is exactly how the documentation explains it.

All you do is continously prove that you are full of shit, sorry. If you are
too stupid to understand inotify or ev_stat watchers, ASK goddamnit, and
don't spill bullshit.

You *can* look up these things.

> 1) "/file" deleted, st_nlink == 0
>    -> libev automatically rearm the event.
> 2) "/file" deleted, st_nlink > 0
>    -> libev continue monitoring "/file"
>    -> application can open a new ev_stat watcher for an eventual,
> upcoming filesystem "/file"

stat() can never return st_nlink = 0 (except maybe if you stat deleted
files in /proc, or some weird race condition in the kernel), so the above
is obviously not applicable. Even if you find an OS where stat returns 0
for st_nlink, this is certainly not something you cna portably rely on.

(sorry, but to talk about something as complicated as inotify and ev_stat,
you should first know the basics).


                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