Subject: Re: [patch] kernel sysfs events layer
From: Robert Love <rml@novell.com>
To: Tim Hockin <thockin@hockin.org>
Cc: Greg KH <greg@kroah.com>, Kay Sievers <kay.sievers@vrfy.org>,
       akpm@osdl.org, linux-kernel@vger.kernel.org
In-Reply-To: <20040915203133.GA18812@hockin.org>
References: <1094875775.10625.5.camel@lucy>
	 <20040911165300.GA17028@kroah.com> <20040913144553.GA10620@vrfy.org>
	 <20040915000753.GA24125@kroah.com> <1095211167.20763.2.camel@localhost>
	 <20040915034455.GB30747@kroah.com> <20040915194018.GC24131@kroah.com>
	 <1095279043.23385.102.camel@betsy.boston.ximian.com>
	 <20040915202234.GA18242@hockin.org>
	 <1095279985.23385.104.camel@betsy.boston.ximian.com>
	 <20040915203133.GA18812@hockin.org>
Content-Type: text/plain
Date: Wed, 15 Sep 2004 16:33:34 -0400
Message-Id: <1095280414.23385.108.camel@betsy.boston.ximian.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 979
Lines: 27

On Wed, 2004-09-15 at 13:31 -0700, Tim Hockin wrote:

> > A mount event should really just cause a rescan of the mount table.
> 
> In which namespace?  All of them?  Is that an information leak that might
> be hazardous (I'm bad with security stuff).

You can only see your own namespace.  So e.g. /proc/mtab is your name
space's mount table and you can rescan that when receiving the mount
signal.

That is sort of the coolness of this approach - push the payload out to
user-space, and we don't have to worry about things like information
leak, name spaces, security, etc.  We are just providing a notify
mechanism for state information that should already be exposed through
sysfs.

So there is no information leak.

	Robert Love


-
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/