Re: [1/1] Use pid in inotify events.

[Robert Love]

The reason John & I did not add a pid field -- and we discussed it and
really wanted it -- is security. It is an information leak to know
what an unrelated process is doing.

Trust me that the rest of the kernel developers are even harder on
this subject than I.

I suppose you could fill out the pid field only if the uid's match,
but that is extra work for less utility.

     Robert


On Sat, Nov 8, 2008 at 11:58 AM, Michael Kerrisk
<mtk.manpages@xxxxxxxxxxxxxx> wrote:
> [CC += "John McCutchan" <ttb@xxxxxxxxxxxxxxxx>, who was one of the
> inotify developers, as I recall]
>
> Hi Evgeniy,
>
> On Sat, Nov 8, 2008 at 10:35 AM, Evgeniy Polyakov <zbr@xxxxxxxxxxx> wrote:
>> Hi Michael.
>>
>> On Sat, Nov 08, 2008 at 09:25:16AM -0500, Michael Kerrisk (mtk.manpages@xxxxxxxxxxxxxx) wrote:
>>> I've not looked closely at the patch, but a quick question.  The
>>> ookied field is unused for _most_ events, but is used for rename
>>> events.  Are you saying that with this patch, that the cookie will be
>>> used as before for rename events, but for other events it will be the
>>> PID of the triggering process?  If so, that seems a bit ugly -- why
>>> wouldn't we also be intersted in the PID for rename events?
>>
>> Yes, rename events actually consist of at least two: move from and move
>> to, and they carry the same cookie, so that userspace could combine them
>> into single transaction. All others use zero, so I decided to put PID of
>> the caller there. This does not look perfect of course, but we can not
>> change the structure layout, so rename events can not be changed to
>> carry additional PID field.
>
> It's perhaps unfortunate that the structure wasn't padded out with a
> few additional fields "for future use".  But -- maybe it is not really
> true that we can't change things.  Two things to consider:
>
> a) We now (since 2.6.27) have an inotify_init1() which has a flags argument.
> b) There are spare bits in the mask argument of inotify_add_watch()
>
> We could use a flag in either of these to say that we want a different
> structure returned on read() from the inotify descriptor.  In the
> first case, this would be a global setting for all inotify events on
> that descriptor.  In the second, we could do it on a per-watch basis
> (I'm not so sure that that is a nice idea).  Since we are in any case
> extending the ABI, and new applications would need to be taught about
> the extension, it seems we could consider either of the alternative
> extensions I mentioned, which woul also allow the PID to be obtained
> for rename() events.  What do you think?
>
> 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/