From: ebiederm@xmission•com (Eric W. Biederman)
To: nicolas.dichtel@6wind•com
Cc: Stephen Hemminger <stephen@networkplumber•org>,
David Miller <davem@davemloft•net>,
yamato@redhat•com, netdev@vger•kernel.org
Subject: Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
Date: Tue, 15 Oct 2013 13:34:39 -0700 [thread overview]
Message-ID: <87a9ias274.fsf@xmission.com> (raw)
In-Reply-To: <525D7109.4010004@6wind.com> (Nicolas Dichtel's message of "Tue, 15 Oct 2013 18:44:57 +0200")
Nicolas Dichtel <nicolas.dichtel@6wind•com> writes:
> Le 10/10/2013 02:17, Eric W. Biederman a écrit :
>>
>> Right.
>>
>> IFLA_NET_NS_PID is not invertible as there may be no processes running
>> in a pid namespace.
>>
>> IFLA_NET_NS_FD is in principle invertible. We just need to add a file
>> descriptor to the callers fd table. I don't see IFLA_NET_NS_FD being
>> invertible for broadcast messages, but for unicast it looks like a bit
>> of a pain but there are no fundamental problems.
> I'm not sure to understand why it is invertible only for unicast message.
> Or are you saying that it is invertible only for the netns where the
> caller stands (and then not for the veth peer)?
The pain is that it is a special case of SCM_RIGHTS aka passing file
descriptors. Right now we don't support SCM_RIGHTS on netlink sockets
and so from that perspective IFLA_NET_NS_FD is a bit of a hack.
For unicast messages we can just stuff a file descriptor in the calling
process and be done with it. For multicast messages we have to be much
more complete.
>> I don't know if we care enough yet to write the code for the
>> IFLA_NET_NS_FD attribute but it is doable.
> I care ;-)
> Has somebody already started to write a patch?
For IFLA_NET_NS_FD not that I know of.
Mostly it is doable but there are some silly cases.
- Do we need to actually implement SCM_RIGHTS to prevent people
accepting file-descriptors unknowingly and hitting their file
descriptor limits.
In which case we need to call the attribute IFLA_NET_NS_SCM_FD
so we knew it was just an index into the passed file descriptors.n
- Do we need an extra permission check to prevent keeping a network
namespace alive longer than necessary? Aka there are some permission
checks opening and bind mounting /proc/<pid>/ns/net do we need
a similar check. Perhaps we would need to require CAP_NET_ADMIN over
the target network namespace.
Beyond that it is just the logistics to open what is essentially
/proc/<pid>/ns/net and add it to the file descriptor table of the
requesting process. Exactly which mount of proc we are going to
find the appropriate file to open I don't know.
It isn't likely to be lots of code but it is code that the necessary
infrastructure is not in place for, and a bunch of moderately hairy
corner cases to deal with.
Eric
next prev parent reply other threads:[~2013-10-15 20:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-04 2:34 [PATCH] veth: Showing peer of veth type dev in ip link (kernel side) Masatake YAMATO
2013-10-08 19:23 ` David Miller
2013-10-08 21:13 ` Stephen Hemminger
2013-10-09 1:52 ` David Miller
[not found] ` <20131009165254.2e1c8332@nehalam.linuxnetplumber.net>
2013-10-10 0:17 ` Eric W. Biederman
2013-10-15 16:44 ` Nicolas Dichtel
2013-10-15 20:34 ` Eric W. Biederman [this message]
2013-10-16 10:08 ` Nicolas Dichtel
2013-10-16 19:53 ` Eric W. Biederman
2013-10-17 16:05 ` Nicolas Dichtel
2013-10-17 19:28 ` Eric W. Biederman
2013-10-18 15:34 ` Nicolas Dichtel
-- strict thread matches above, loose matches on Subject: below --
2013-10-04 4:05 Masatake YAMATO
2013-10-04 4:49 ` Eric Dumazet
2013-10-04 15:21 ` Nicolas Dichtel
2013-10-04 17:55 ` Stephen Hemminger
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=87a9ias274.fsf@xmission.com \
--to=ebiederm@xmission$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nicolas.dichtel@6wind$(echo .)com \
--cc=stephen@networkplumber$(echo .)org \
--cc=yamato@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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