linux-kernel - Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Sep 2014 09:45:30 -0700
From:	Cong Wang <cwang@...pensource.com>
To:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:	netdev <netdev@...r.kernel.org>,
	containers@...ts.linux-foundation.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-api@...r.kernel.org, David Miller <davem@...emloft.net>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>
Subject: Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns

On Wed, Sep 24, 2014 at 9:27 AM, Nicolas Dichtel
<nicolas.dichtel@...nd.com> 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.

>   - the encapsulation addresses are not part of this netns but the user
> doesn't
>     known that (still because netns info is missing). These IPv4 addresses
> may
>     exist into this netns.

I don't remember your x-netns code, but we have two choices:

1) Lookup the route of the netns which it is in

If the address is not available in this netns, it will fail, this is expected
since tunnel device is not a pure L2 device. Or maybe just fail
early when we move it.

2) Lookup the route of the netns where it was created

Transparent for upper layer, but as you said, the outer address is not
available in this netns therefore hard to display. Just hiding this information
doesn't seem wrong to me.

>   - it's not possible to create the same netdevice with these infos.
>

This is expected, because after all you are already in a different netns.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/