netdev - Re: new link failing on duplicate names in different namespaces

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: <8761apubru.fsf@x220.int.ebiederm.org>
Date:	Wed, 25 Feb 2015 11:44:05 -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: new link failing on duplicate names in different namespaces

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

> Le 25/02/2015 01:48, Eugene Yakubovich a écrit :
>> Hello,
>>
>> rtnetlink's RTM_NEWLINK allows for specifying the network namespace in
>> which the link is to be created via IFLA_NET_NS_PID or IFLA_NET_NS_FD.
>> This not only saves a user a call to move the link into the target
>> namespace, it can avoid a potential ifname conflict. For example, if
>> creating eth0 in another namespace and the current one already has
>> eth0.
>>
>> Unfortunately, this is not the current behavior. If the user specifies
>> IFLA_IFNAME, leaves ifinfomsg.ifi_index unspecified and sets
>> NLM_F_EXCL flag, as in the case of creating a new link, the call will
>> fail with EEXIST in cases where there's a name conflict.
>>
>> rtnl_newlink() will:
>>
>> if (ifname[0])
>>      dev = __dev_get_by_name(net, ifname);
> Yes, it seems that this should be done in "dest_net" or "link_net".

Ugh.  Looking at that code I think the link_net is at best extremely
confusing most likely semantically broken the way it is being
interpreted in rtnl_newlink.  More in another email message.

The original semantics and what seems mostly reasonable because the
network device in some sense lives in multiple network namespaces
as it is being created is that the network device name be unique
in both namespaces.

The code that creates a network devices fundamentally needs to know
about both namespaces network devices like the macvlan driver need
to find their lower devices in the original network namespace.

I think we could possibly remove the restriction for the names of newly
created network devices being unique in both network namespaces but I
don't think the code changes will be trivial.

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