From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933026AbbFINAL (ORCPT <rfc822;w@1wt.eu>);
	Tue, 9 Jun 2015 09:00:11 -0400
Received: from out01.mta.xmission.com ([166.70.13.231]:39251 "EHLO
	out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932561AbbFIM7u (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 9 Jun 2015 08:59:50 -0400
From: ebiederm@xmission.com (Eric W. Biederman)
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
        "linux-unionfs\@vger.kernel.org" <linux-unionfs@vger.kernel.org>,
        Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
        Kernel Mailing List <linux-kernel@vger.kernel.org>,
        sa <sa-dev@rainbow.by>, "Roth\, Andre" <andre.roth@roche.com>
References: <1433424586-7771-1-git-send-email-miklos@szeredi.hu>
	<1433424586-7771-3-git-send-email-miklos@szeredi.hu>
	<20150605000715.GP7232@ZenIV.linux.org.uk>
	<20150605150939.GA2174@tucsk> <877frgwcsf.fsf@x220.int.ebiederm.org>
	<CAJfpegtM4KnKA+isDTDpakJcaYJT5nhN=pQUJx8Hs58SsondJA@mail.gmail.com>
Date: Tue, 09 Jun 2015 07:54:37 -0500
In-Reply-To: <CAJfpegtM4KnKA+isDTDpakJcaYJT5nhN=pQUJx8Hs58SsondJA@mail.gmail.com>
	(Miklos Szeredi's message of "Tue, 9 Jun 2015 14:44:09 +0200")
Message-ID: <87sia1rqia.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-XM-AID: U2FsdGVkX18W76mKLQDO/0xuYdXmNnS7FGMPuHabWoQ=
X-SA-Exim-Connect-IP: 67.3.205.90
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	*  0.0 TVD_RCVD_IP Message was received from an IP address
	*  1.5 XMNoVowels Alpha-numberic number with no vowels
	*  0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.
	*  0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
	*      [score: 0.5000]
	* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
	*      [sa06 1397; Body=1 Fuz1=1 Fuz2=1]
X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: *;Miklos Szeredi <miklos@szeredi.hu>
X-Spam-Relay-Country: 
X-Spam-Timing: total 438 ms - load_scoreonly_sql: 0.09 (0.0%),
	signal_user_changed: 4.1 (0.9%), b_tie_ro: 2.9 (0.7%), parse: 1.05 (0.2%),
	extract_message_metadata: 17 (3.9%), get_uri_detail_list: 1.63 (0.4%),
	tests_pri_-1000: 7 (1.6%), tests_pri_-950: 1.34 (0.3%), tests_pri_-900: 1.12
	(0.3%), tests_pri_-400: 20 (4.6%), check_bayes: 19 (4.3%), b_tokenize: 5
	(1.2%), b_tok_get_all: 7 (1.7%), b_comp_prob: 1.84 (0.4%), b_tok_touch_all:
	2.4 (0.6%), b_finish: 0.73 (0.2%), tests_pri_0: 378 (86.3%), tests_pri_500: 5
	(1.2%), rewrite_mail: 0.00 (0.0%)
Subject: Re: [PATCH 2/2] ovl: allow distributed fs as lower layer
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi <miklos@szeredi.hu> writes:

> On Sun, Jun 7, 2015 at 3:02 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> A nasty corner case to be aware of (and I think this is part of what Al
>> was warning about).  /proc/sys/net is different depending upon which
>> current->nsproxy->net_ns.
>
> Ah,  I'm beginning to grasp what's going on there: mulitple dentries
> with the same name but belonging to different namespaces,
> ->d_compare() being used to select the right one.  Is that it?

Yes.  The whole sysctl_is_seen magic.

I am not proud of it, and I keep thinking I should create
/proc/<pid>/sys/...  making /proc/sys a symlink to /proc/<pid>/sys/

so that case could go away.  Although at this point tomoyo or apparmor
probably has rules that would make that impossible (despite no
applications actually caring). *sigh*

> Overlayfs checks for d_compare() on the root of the lower and upper
> trees, but here it only set on a subdirectory of proc, not on every
> dentry.  So overlayfs should be careful and check for
> DCACHE_OP_COMPARE | DCACHE_OP_HASH and reject going down such a
> dentry.

That sound about right.

Eric