netdev - Re: What are the intended semantics of IFLA_LINK

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]

Message-ID: <87wq34okb9.fsf@x220.int.ebiederm.org>
Date:	Thu, 26 Feb 2015 07:48:26 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	nicolas.dichtel@...nd.com
Cc:	Eugene Yakubovich <eugene.yakubovich@...eos.com>,
	netdev@...r.kernel.org
Subject: Re: What are the intended semantics of IFLA_LINK_NETNSID?

Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:

> Le 25/02/2015 20:03, Eric W. Biederman a écrit :
>>
>> Reading through the code of rtnl_newlink I am perplexed with what your
>> intended semantics of IFLA_LINK_NETNSID are supposed to be.
>>
>> My expectation was something with the same semantics IFLA_NET_NS_PID and
>> IFLA_NET_NS_FD just a different data representation and something that
>> could be used in more netlink messages, so you could report the network
>> namespace where the other end of a tunnel or the the network namespace
>> of an underlying device is.
>>
>> Being very slow I would expect that ILFA_LINK_NETNSID would replace
>> dest_net or possibly net in rtnl_newlink but it does not replace either
>> of those completely.  Which causes me to think that the implementation
>> of IFLA_LINK_NETNSID in rtnl_newlink is broken.
>>
>> I suspect the correct fix for rtnl_newlink is to just use
>> IFLA_LINK_NETNSID in rtnl_link_get_net and have it be an alternative way
>> of setting dest_net.  But you may intend some different semantics that
>> I don't understand.
> ILFA_LINK_NETNSID is used to point to the i/o netns of the interface, ie the
> opposite netns of dest_net.

Fair enough.  That makes sense given how it is used in the reporting.
With those semantics the code may arguably be correct.

> The interface is first created in link_net and moved at the end in dest_net.
>
> IP tunnels interfaces (ipip, sit, ip6_tunnels, gre[v6]) does not use src_net,

I am pretty certain that is simply something that was overlooked when
cross network namespace support was added to those network device types.
Right now I would be surprised if anything in userspace cares, so we can
probably just change those device types to look at src_net from newlink.

Certainly for our sanity in maintaining rtnl_newlink finding a way to
make that change would be preferable.  Even if we ultimately have to add
a flag that says only make src_net different from dev->net when
IFLA_LINK_NETNSID is passed.

As making that change allows much more consistency in the code and
allows us to get rid of an unnecessary dev_change_net_namespace.

> thus when you create an ipip interface by specifying an attribute
> IFLA_NET_NS_PID it will result to an interface which is not across two netns but
> only in the netns pointed by IFLA_NET_NS_PID. If you use IFLA_LINK_NETNSID, it
> allows you to create this kind of x-netns interfaces.
> In fact, the goal of this attribute is to replace the two following command by
> only one:
> ip link add foo ...
> ip link set foo netns bar
> => ip link add foo link-netnsid barID

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html