From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755173AbYB1VUl (ORCPT ); Thu, 28 Feb 2008 16:20:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1762669AbYB1VUH (ORCPT ); Thu, 28 Feb 2008 16:20:07 -0500 Received: from smtp114.sbc.mail.re2.yahoo.com ([68.142.229.91]:30498 "HELO smtp114.sbc.mail.re2.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1760527AbYB1VUF (ORCPT ); Thu, 28 Feb 2008 16:20:05 -0500 X-YMail-OSG: aimf760VM1mLDc2T_cyZDHpmrdvTB3j85lwdeKTyOJqpJ7WqeABnQkGWK_OOqfnYwkJNvoS8kcl6kh5MjQs3cFUEa7uywYmyef3pGStYpOlclLmRwi6ySjRFwVPu.XsFncTFBlDQTqMx5r4- X-Yahoo-Newman-Property: ymail-3 Date: Thu, 28 Feb 2008 15:17:20 -0600 From: serge@hallyn.com To: "Eric W. Biederman" Cc: Pavel Emelyanov , Andrew Morton , David Miller , Alexey Dobriyan , Linux Netdev List , Linux Kernel Mailing List Subject: Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces Message-ID: <20080228211720.GA1232@vino.hallyn.com> References: <47C6D743.1050802@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Eric W. Biederman (ebiederm@xmission.com): > Pavel Emelyanov writes: > > > Current /proc/net is done with so called "shadows", but current > > implementation is broken and has little chances to get fixed. > > > > The problem is that dentries subtree of /proc/net directory has > > fancy revalidation rules to make processes living in different > > net namespaces see different entries in /proc/net subtree, but > > currently, tasks see in the /proc/net subdir the contents of any > > other namespace, depending on who opened the file first. > > > > The proposed fix is to turn /proc/net into a symlink, which behaves > > similar to /proc/self link - it points to .netns/ directory > > where the is the id of net namespace, current task lives in. > > > > # ls -l /proc/net > > lrwxrwxrwx 1 root root 8 Feb 28 18:38 /proc/net -> .netns/0 > > > > The /proc/.netns dir contains subtrees for all the namespaces in > > the system: > > > > # ls -l /proc/.netns/ > > total 0 > > dr-xr-xr-x 5 root root 0 Feb 28 18:39 0 > > dr-xr-xr-x 3 root root 0 Feb 28 18:39 1 > > > > To provide some security each /proc/.netns/ directory allows > > access to tasks that live in the owning namespace only (with the > > exception, that init_net tasks can see everything). > > > Nack. Yet another global set of ids that require us to implement another > namespace looks like the wrong way to go. Sentiment granted, but I'm not sure it can be an issue. It *could* be in issue if we moved to a more flexible access control here here any netns could access the .netns/N directories for all it's child namespaces. But it can't, and /proc/net is set by the kernel. So the can't be an issue for any checkpoint/restart except htat of the whole system, and of course on whole-system resume we have no collision worries. So userspace can't do anything with , so there is no reason to worry about it becoming another namespace? Right? thanks, -serge > Can you try this approach by capturing a struct pid instead of an id > in a new global namespace? > > In particular the pid of the process that creates the pid namespace. > Like we do with setsid. > > I think the implementation difficulty should be about the same, but > it will allow us something that works cleanly in the cases of > migration and nested namespaces. As well as not adding an unnecessary > special case with init_net and visibility. > > Eric > -- > 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/