Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Christian Brauner <christian.brauner@ubuntu.com>
To:     davem@davemloft.net, dsahern@gmail.com, fw@strlen.de,
        daniel@iogearbox.net, lucien.xin@gmail.com,
        mschiffer@universe-factory.net, jakub.kicinski@netronome.com,
        vyasevich@gmail.com, jbenc@redhat.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Cc:     Christian Brauner <christian.brauner@ubuntu.com>
Subject: [PATCH net-next 0/1] rtnetlink: request RTM_GETLINK by pid or fd
Date:   Thu, 18 Jan 2018 21:21:23 +0100
Message-Id: <20180118202124.21616-1-christian.brauner@ubuntu.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hey everyone,

This makes it possible to identify the target network namespace of a
RTM_GETLINK message by pid or fd.
Often userspace tools that make heavy use of network namespaces need a simple
and cheap way of querying network devices and network device properties. This
becomes even more crucial when the network namespaces in question are
transient. In such scenarios setting a netns id property is not really wanted
and it is preferable to avoid the hit of (possibly multiple) setns() syscalls
(e.g. attaching to the target network namespace and back to the original
network namespace.). This commit lets userspace set the IFLA_NET_NS_{FD,PID}
property to identify a target network namespace where the device in question is
to be queried.
I couldn't find any obvious reason why this shouldn't be allowed but I haven't
done a deep dive into the possible security implications. So if I missed a very
obvious point why this wasn't possible so far, I'm sorry.

Christian

Christian Brauner (1):
  rtnetlink: request RTM_GETLINK by pid or fd

 net/core/rtnetlink.c | 63 +++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 50 insertions(+), 13 deletions(-)

-- 
2.14.1