From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Dichtel Subject: Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns Date: Fri, 26 Sep 2014 15:40:27 +0200 Message-ID: <54256CCB.4000709@6wind.com> References: <1411478430-4989-1-git-send-email-nicolas.dichtel@6wind.com> <54228D87.3070309@6wind.com> <5422F0F4.6000709@6wind.com> <5423D80B.9060500@6wind.com> Reply-To: nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Cong Wang Cc: netdev , containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Andy Lutomirski , Stephen Hemminger , "Eric W. Biederman" , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrew Morton , David Miller List-Id: containers.vger.kernel.org TGUgMjYvMDkvMjAxNCAwNDowOSwgQ29uZyBXYW5nIGEgw6ljcml0IDoKPiBPbiBUaHUsIFNlcCAy NSwgMjAxNCBhdCAxOjUzIEFNLCBOaWNvbGFzIERpY2h0ZWwKPiA8bmljb2xhcy5kaWNodGVsQDZ3 aW5kLmNvbT4gd3JvdGU6Cj4+IExlIDI0LzA5LzIwMTQgMTg6NDUsIENvbmcgV2FuZyBhIMOpY3Jp dCA6Cj4+Pgo+Pj4gT24gV2VkLCBTZXAgMjQsIDIwMTQgYXQgOToyNyBBTSwgTmljb2xhcyBEaWNo dGVsCj4+PiA8bmljb2xhcy5kaWNodGVsQDZ3aW5kLmNvbT4gd3JvdGU6Cj4+Pj4KPj4+PiBOb3cg aW5mb3JtYXRpb25zIGdvdCB3aXRoICdpcCBsaW5rJyBhcmUgd3JvbmcgYW5kIGluY29tcGxldGU6 Cj4+Pj4gICAgIC0gdGhlIGxpbmsgZGV2IGlzIG5vdyB0dW5sMCBpbnN0ZWFkIG9mIGV0aDAsIGJl Y2F1c2Ugd2Ugb25seSBnb3QgYW4KPj4+PiBpZmluZGV4Cj4+Pj4gICAgICAgZnJvbSB0aGUga2Vy bmVsIHdpdGhvdXQgYW55IG5ldG5zIGluZm9ybWF0aW9ucy4KPj4+Cj4+Pgo+Pj4gVGhpcyBpcyBu b3QgbmV3LCBtYWN2bGFuIGhhcyB0aGUgc2FtZSBwcm9ibGVtLiBUaGlzIGlzIHdoeSBJIHNhaWQK Pj4+IGl0IGlzIG1vc3RseSBhIGRpc3BsYXkgcHJvYmxlbSwgbWF5YmUganVzdCBtYXJrIHRoZSBp ZmluZGV4IGFzIC0xIG9yCj4+PiBzb21ldGhpbmcgd2hlbiBpdCBpcyBub3QgaW4gdGhpcyBuZXRu cy4gQXQgbGVhc3QgSSBkb24ndCBleHBlY3QgdGhlIGlubmVyCj4+PiBuZXRucyBrbm93IGFueXRo aW5nIG91dHNpZGUsIGFuZCBJIGRvbid0IHRoaW5rIEkgYW0gdGhlIG9ubHkgb25lIHVzaW5nCj4+ PiBuZXRucyBpbiB0aGlzIHdheS4KPj4KPj4gSSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQgYnV0IHRo ZXJlIGlzIHNldmVyYWwgdXNlIG9mIG5ldG5zLiBOZXRucyBjYW4gYmUgdXNlZAo+PiBhbHNvIHRv IGluc3RhbnRpYXRlIHZpcnR1YWwgcm91dGVycy4gSW4gdGhpcyBjYXNlLCBhZG1pbmlzdHJhdG9y cyBvciBkYWVtb25zCj4+IG5lZWQgdG8gYmUgYWJsZSB0byBtb25pdG9yIGFuZCBkdW1wIHRoZSBj b25maWd1cmF0aW9uIG9uIGFsbCBuZXRucwo+PiAocGFydGljdWxhcmx5IGJlZWluZyBhYmxlIHRv IGlkZW50aWZ5IGZ1bGx5IHgtbmV0bnMgaW50ZXJmYWNlcykuIFdlIHN0YXJ0IHRvCj4+IGRpc2N1 c3MgdGhpcyBpbiBvbmUgb2YgdGhlIHR3byB0aHJlYWQgcG9pbnRlZCBpbiBteSBjb3ZlciBsZXR0 ZXIgYW5kIGdldCB0aGUKPj4gY29uY2x1c2lvbiB0aGF0IGNoZWNraW5nIHVzZXIgbnMgaXMgYSBn b29kIHdheSB0byBrbm93IGlmIGFuIGlkIHNob3VsZCBiZQo+PiBkaXNjbG9zZWQgb3Igbm90IGZv ciBhIHBlZXIgbmV0bnMuCj4KPiBUaGVuIHlvdSBhcmUgbGVha2luZyBpbmZvcm1hdGlvbiwgdGhp cyBicmVha3MgaXNvbGF0aW9uLgo+Cj4+IENhbiB5b3UgZGVzY3JpYmUgeW91ciB1c2UgY2FzZT8K Pgo+IFllcywgdG9vIHNpbXBsZTogaXNvbGF0aW9uIG5ldHdvcmtpbmcsIGRpZmZlcmVudCBuZXRu cydzIGRvbid0IHNlZSBlYWNoIG90aGVyCj4gKGluY2x1ZGluZyBhbnl0aGluZyBpbnNpZGUpIGFu ZCBvbmx5IGNvbW11bmljYXRlIHZpYSB2ZXRoLgpJZiB5b3UgYXJlIGEgcHJpdmlsZWdlZCB1c2Vy IGFuZCB5b3UgYXJlIGFibGUgdG8gYWNjZXNzIGEgcGVlciBuZXRucyAobW92ZSBhbgppbnRlcmZh Y2UgaW50byB0aGlzIHBlZXIgbmV0bnMsIG1vdmUgYW4gaW50ZXJmYWNlIGZyb20gdGhpcyBwZWVy IG5ldG5zIHRvIHlvdXIKb3duIG5ldG5zKSwgSSBkb24ndCBzZWUgYW55IHJlYXNvbiB0byBub3Qg YmVlaW5nIGFibGUgdG8gZ2V0IGluZm9ybWF0aW9uIGFib3V0CnRoaXMgcGVlciBuZXRucyAoeW91 IGFyZSBhbHJlYWR5IGEgcHJpdmlsZWdlZCB1c2VyIGluIGJvdGggbmV0bnMpLgpJZiB5b3Ugd2Fu dCB0byBpc29sYXRlIHRoaXMgcGVlciBuZXRucyAoSSB0aGluayB5b3UgY2FsbCBpdCAiaW5uZXIg bmV0bnMiKSwgeW91CmhhdmUgdG8gY3JlYXRlIGEgbmV3IHVzZXIgbnMgZm9yIHRoaXMgbmV0bnMs IGhlbmNlIGEgcHJpdmlsZWdlZCB1c2VyIGludG8gdGhpcwpwZWVyIG5ldG5zIHdpbGwgbm90IGJl IGFibGUgdG8gYWN0IGluIHlvdXIgb3duIG5ldG5zLiBBbmQgd2l0aCB0aGlzIHNjZW5hcmlvIGFu ZApteSBwYXRjaGVzLCB0aGlzIHByaXZpbGVnZWQgdXNlciB3aWxsIG5vdCBiZSBhYmxlIHRvIGdl dCBhbiBpZC4gSXNvbGF0aW9uIGlzCnByZXNlcnZlZC4KSG93IGRvIHlvdSBwcmVzZXJ2ZWQgaXQg aW4geW91ciBzY2VuYXJpbz8KCj4KPgo+PiBJZiB5b3Ugb25seSBwbGF5IHdpdGggbmV0bnMsIHlv dSBtYXkgd2FudCB0byBtb25pdG9yIGFsbCBhY3RpdmllcyBpbiBhbGwKPj4gbmV0bnMKPj4gKHRo aXMgaXMgYWxyZWFkeSBwb3NzaWJsZSkgYW5kIGJlZWluZyBhYmxlIHRvIGxpbmsgaW5mb3JtYXRp b24gYmV0d2VlbiBuZXRucwo+PiAodGhpcyBpcyB3aGF0IEknbSB0cnlpbmcgdG8gc29sdmUpLgo+ Cj4KPiBObywgSSBkb24ndCB3YW50IHRvIG1vbml0b3IgYW55dGhpbmcuIEV2ZW4gaWYgSSB3YW50 ZWQsIEkgd291bGQganVzdCBzdGFydCBvbmUKPiBkYWVtb24gaW4gZWFjaCBuZXRucyBpbnN0ZWFk IG9mIG9uZSBmb3IgYWxsLgpPayB5b3UgZG9uJ3Qgd2FudCwgYnV0IHNvbWUgb3RoZXIgcGVvcGxl IChub3Qgb25seSBtZSkgd2FudCBpdCEgQW5kIGhhdmluZyBvbmUKZGFlbW9uIHBlciBuZXRucyBk b2VzIG5vdCBzY2FsZTogdGhlcmUgYXJlIHNjZW5hcmlpIHdpdGggdGhvdXNhbmQgbmV0bnMgd2hp Y2gKYXJlIGR5bmFtaWNhbGx5IGNyZWF0ZWQgYW5kIGRlbGV0ZWQuCgo+Cj4gT24gdGhlIG90aGVy IGhhbmQsIHdoeSBub3QgZXhjaGFuZ2UgdGhlIGNvbmZpZ3VyYXRpb24gdmlhIHZldGgKPiBiZXR3 ZWVuIGRpZmZlcmVudCBuZXRucz8gVGhlcmUgYXJlIG1hbnkgd2F5cyB0byBkbyBzbyB3aXRoIFRD UCBIVFRQIGV0Yy4KPiBUaGlzIGRvZXNuJ3QgaGF2ZSB0byBiZSBzb2x2ZWQgaW4ga2VybmVsLgo+ ClRoZSBzdGFuZGFyZCB3YXkgd2l0aCBsaW51eCB0byBtb25pdG9yIG5ldHdvcmsgY29uZmlndXJh dGlvbiBpcyBuZXRsaW5rLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpDb250YWluZXJzIG1haWxpbmcgbGlzdApDb250YWluZXJzQGxpc3RzLmxpbnV4LWZv dW5kYXRpb24ub3JnCmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9uLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NvbnRhaW5lcnM= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755367AbaIZNkf (ORCPT ); Fri, 26 Sep 2014 09:40:35 -0400 Received: from mail-wg0-f50.google.com ([74.125.82.50]:36501 "EHLO mail-wg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754610AbaIZNk3 (ORCPT ); Fri, 26 Sep 2014 09:40:29 -0400 Message-ID: <54256CCB.4000709@6wind.com> Date: Fri, 26 Sep 2014 15:40:27 +0200 From: Nicolas Dichtel Reply-To: nicolas.dichtel@6wind.com Organization: 6WIND User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Cong Wang CC: netdev , containers@lists.linux-foundation.org, "linux-kernel@vger.kernel.org" , linux-api@vger.kernel.org, David Miller , "Eric W. Biederman" , Stephen Hemminger , Andrew Morton , Andy Lutomirski Subject: Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns References: <1411478430-4989-1-git-send-email-nicolas.dichtel@6wind.com> <54228D87.3070309@6wind.com> <5422F0F4.6000709@6wind.com> <5423D80B.9060500@6wind.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 26/09/2014 04:09, Cong Wang a écrit : > On Thu, Sep 25, 2014 at 1:53 AM, Nicolas Dichtel > wrote: >> Le 24/09/2014 18:45, Cong Wang a écrit : >>> >>> On Wed, Sep 24, 2014 at 9:27 AM, Nicolas Dichtel >>> wrote: >>>> >>>> Now informations got with 'ip link' are wrong and incomplete: >>>> - the link dev is now tunl0 instead of eth0, because we only got an >>>> ifindex >>>> from the kernel without any netns informations. >>> >>> >>> This is not new, macvlan has the same problem. This is why I said >>> it is mostly a display problem, maybe just mark the ifindex as -1 or >>> something when it is not in this netns. At least I don't expect the inner >>> netns know anything outside, and I don't think I am the only one using >>> netns in this way. >> >> I understand your point but there is several use of netns. Netns can be used >> also to instantiate virtual routers. In this case, administrators or daemons >> need to be able to monitor and dump the configuration on all netns >> (particularly beeing able to identify fully x-netns interfaces). We start to >> discuss this in one of the two thread pointed in my cover letter and get the >> conclusion that checking user ns is a good way to know if an id should be >> disclosed or not for a peer netns. > > Then you are leaking information, this breaks isolation. > >> Can you describe your use case? > > Yes, too simple: isolation networking, different netns's don't see each other > (including anything inside) and only communicate via veth. If you are a privileged user and you are able to access a peer netns (move an interface into this peer netns, move an interface from this peer netns to your own netns), I don't see any reason to not beeing able to get information about this peer netns (you are already a privileged user in both netns). If you want to isolate this peer netns (I think you call it "inner netns"), you have to create a new user ns for this netns, hence a privileged user into this peer netns will not be able to act in your own netns. And with this scenario and my patches, this privileged user will not be able to get an id. Isolation is preserved. How do you preserved it in your scenario? > > >> If you only play with netns, you may want to monitor all activies in all >> netns >> (this is already possible) and beeing able to link information between netns >> (this is what I'm trying to solve). > > > No, I don't want to monitor anything. Even if I wanted, I would just start one > daemon in each netns instead of one for all. Ok you don't want, but some other people (not only me) want it! And having one daemon per netns does not scale: there are scenarii with thousand netns which are dynamically created and deleted. > > On the other hand, why not exchange the configuration via veth > between different netns? There are many ways to do so with TCP HTTP etc. > This doesn't have to be solved in kernel. > The standard way with linux to monitor network configuration is netlink.