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

[Evgeniy Polyakov <zbr-i6C2adt8DTjR7s880joybQ@public.gmane.org>]

Hi Michael.

On Wed, Nov 19, 2008 at 09:34:46AM -0500, Michael Kerrisk (mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org) wrote:
> > 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?

> > 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.

-- 
	Evgeniy Polyakov
--
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