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 [thread overview]
Message-ID: <20180118202124.21616-1-christian.brauner@ubuntu.com> (raw)
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
next reply other threads:[~2018-01-18 20:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-18 20:21 Christian Brauner [this message]
2018-01-18 20:21 ` [PATCH net-next 1/1] " Christian Brauner
2018-01-18 20:29 ` Jiri Benc
2018-01-18 20:55 ` Christian Brauner
2018-01-22 21:00 ` Jiri Benc
2018-01-22 21:23 ` Christian Brauner
2018-01-22 22:06 ` Jiri Benc
2018-01-22 22:25 ` Christian Brauner
2018-01-23 9:30 ` Jiri Benc
2018-01-23 10:26 ` Wolfgang Bumiller
2018-01-23 10:42 ` Jiri Benc
2018-01-23 16:50 ` Nicolas Dichtel
2018-01-23 16:37 ` Nicolas Dichtel
2018-01-23 17:08 ` Jiri Benc
2018-01-24 10:53 ` Nicolas Dichtel
2018-01-24 11:03 ` Jiri Benc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180118202124.21616-1-christian.brauner@ubuntu.com \
--to=christian.brauner@ubuntu.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=fw@strlen.de \
--cc=jakub.kicinski@netronome.com \
--cc=jbenc@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=mschiffer@universe-factory.net \
--cc=netdev@vger.kernel.org \
--cc=vyasevich@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®