Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754201AbYKSOyR (ORCPT ); Wed, 19 Nov 2008 09:54:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753963AbYKSOxx (ORCPT ); Wed, 19 Nov 2008 09:53:53 -0500 Received: from genesysrack.ru ([195.178.208.66]:48924 "EHLO tservice.net.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753926AbYKSOxw (ORCPT ); Wed, 19 Nov 2008 09:53:52 -0500 Date: Wed, 19 Nov 2008 17:53:51 +0300 From: Evgeniy Polyakov To: mtk.manpages@gmail.com Cc: Christoph Hellwig , Robert Love , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , john@johnmccutchan.com Subject: Re: [take 3] Use pid in inotify events. Message-ID: <20081119145351.GA2652@ioremap.net> References: <20081116232450.GA13547@ioremap.net> <20081118131937.GC16944@lst.de> <20081119140500.GA25968@ioremap.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2034 Lines: 46 Hi Michael. On Wed, Nov 19, 2008 at 09:34:46AM -0500, Michael Kerrisk (mtk.manpages@googlemail.com) 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/