[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081117171508.GA564@ioremap.net>
Date: Mon, 17 Nov 2008 20:15:08 +0300
From: Evgeniy Polyakov <zbr@...emap.net>
To: mtk.manpages@...il.com
Cc: Robert Love <rlove@...ve.org>, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Christoph Hellwig <hch@....de>
Subject: Re: [take 3] Use pid in inotify events.
Hi Michael.
On Mon, Nov 17, 2008 at 11:59:11AM -0500, Michael Kerrisk (mtk.manpages@...glemail.com) wrote:
> 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. Extending
(rewriting userspace event processing part) events is a solution for the
new project, while existing patch (where all security concerns are
resolved) is a minimum functionality extension.
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, and for the purpose of reporting origin's PID cookie
fields can be reused since right now it is unused.
Plus, if it is that hard to comment on patch which adds 14 (!) lines
including blank, which feedback we should expect on larger one? :)
--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists