Re: [take 3] Use pid in inotify events.

On Wed, Nov 19, 2008 at 6:53 AM, Evgeniy Polyakov [off-list ref] wrote:

Hi Michael.

On Wed, Nov 19, 2008 at 09:34:46AM -0500, Michael Kerrisk (mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org) wrote:

quoted

quoted

So effectively you propose to have second generation of the inotify
which will have additional pid field, which will be unused by all but
the same uid events?

I susepect that Christoph wants the same thing as I do: some thinking
towards a future-proof design, rather than a quick hack to address the needs
of a single application.

So far the only real need is a pid. That will solve the cases I'm
working on and it may be interesting for other applications. It is
possible to extend read/write IO with offset and size parameters though.

Do you see any other possible extensions?

quoted

quoted

If you want to return -EPERM, than it will be _always_ returned for non
sysadmin capable user, which effectively makes it unusable.

Again, appropriate flags in inotify_init1() could fix this -- e.g., only
fill the field (and give an error if no perms) if a flag is set.

Um, hmm... Permission is _always_ denied for 'alien' IO, as it was
pointed by Robert, at init time there is no way to know, will there be
alien IO (i.e. originated by the process with different uid) or not.
More on this: inotify initialization is just a memory allocation in
the kernel, nothing more.

We can argue about object insertion into inotify queue though. But
again, we check already that it has read permissions, and if so, we are
allowed to receive notificatons about IO against given target, since if
new code will return for whatever reason -EPERM, people will use old
code.

So, putting PID/whatever else into event can be flag-driven, but there
is no way to return EPERM anywhere in the call chain not breaking
backward compatibility of the whole idea.

I really don't like the idea of overloading the cookie field to store
the pid for only the events that don't already use the cookie field.

Coming into this late, maybe I missed it but can you explain why you
need the pid that caused the event?

-- 
John McCutchan [off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html