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

[RESENT, because LKML bounced some HTML that accidentally got put in the mail.]
[CC+=John McCutchan, this time with hopefully a live email address;
John, some context here: http://marc.info/?t=122633022400003&r=1&w=2 ]

Evgeniy,

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

Hi Christoph.

On Tue, Nov 18, 2008 at 02:19:37PM +0100, Christoph Hellwig (hch-jcswGhMUV9g@public.gmane.org) wrote:

quoted

Yes, this kind of thing should be enable using an flag to inotify1, and
be consistant even for rename.  Doing it as a flag to inotify1 also has
the advantage to be able to return an -EPERM when the feature is
requested but not allowed instead of letting applications that assume it
silently fail.

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

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.

I think what is really needed at this point is some consideration of
what other extensions (if any) might be desired for inotify, and how
we might be best create a design that suits those and future needs.

Cheers,

Michael


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
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