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

Hi Evgeniy,

On Mon, Nov 17, 2008 at 12:15 PM, Evgeniy Polyakov [off-list ref] wrote:

Hi Michael.

On Mon, Nov 17, 2008 at 11:59:11AM -0500, Michael Kerrisk (mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org) wrote:

quoted

NAK.  If we are going to do this -- and I leave the security
discussions to others more knowlegeable on that score than me -- then
the API design should be better than this.  The current design is a
hack.  Why exclude rename events?  Why re-use the cookie field?  The
only answers I can guess at are that the current patch is less work to
write.  IMO, there are (much) better design possibilities, using
inotify1(), as I suggested earlier in this thread.

Cookie was created to store information used to somehow connect events to
each other. PID does that from another angle than rename.

Yes, but it does it in an inconsistent, incomplete way.

Extending
(rewriting userspace event processing part) events is a solution for the
new project,

Not quite sure of your point here.  Whatever change is made, userspace
apps will need to be trained to understand the interface.

while existing patch (where all security concerns are
resolved) is a minimum functionality extension.

It is a minimum functionality extension that serves the needs of one
or a few projects, while dirtying the design for all users.

if I will spent a day and rewrite userspace report side to report new
events I'm pretty sure there will be people, who will start complaining
that again design does not match some theoretically perfect
expectations,

Maybe.  Mabe not.  But that is (a necessary) part of the design process.

and for the purpose of reporting origin's PID cookie
fields can be reused since right now it is unused.

You didn't really respond to my earlier comment.  Why are you doing
things this way.  As far as I can see, only becuase it is quicker to
implement.

Plus, if it is that hard to comment on patch which adds 14 (!) lines
including blank, which feedback we should expect on larger one? :)

Still NAK, sorry.

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