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: Wed, 16 Oct 2013 12:53:11 -0700 [thread overview]
Message-ID: <87txghm1qw.fsf@xmission.com> (raw)
In-Reply-To: <525E659C.3000305@6wind.com> (Nicolas Dichtel's message of "Wed, 16 Oct 2013 12:08:28 +0200")
Nicolas Dichtel <nicolas.dichtel@6wind•com> writes:
> Le 15/10/2013 22:34, Eric W. Biederman a écrit :
>> 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.
> Got it. This doesn't seems the simpliest/best way to resolve this pb.
> Can we not introduce another identifier (something like IFLA_NET_NS_ID),
> which will not have such constraint?
> inode is unique on the system, why not using it as an opaque value to
> identitfy the netns (like 'ip netns identify' do)?
The age old question why can't we have global identifiers for
namespaces?
The answer is that I don't want to implement a namespace for namespaces.
While the proc inode does work today across different mounts of proc, I
reserve the right at some future date (if it solves a technical problem)
to give each namespace a different inode number in each different mount
of proc. So the inode number is not quite the unique identifier you
want. The inode number is a close as I am willing to get to a namespace
of namespaces.
I think the simplest solution is to just not worry about which namespace
the other half of a veth pair is in. But I have not encountered the
problem where I need to know exactly which namespace we are worrying
about.
Global identifiers are easy until you hit the cases where they make
things impossible.
Eric
next prev parent reply other threads:[~2013-10-16 19:53 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
2013-10-16 10:08 ` Nicolas Dichtel
2013-10-16 19:53 ` Eric W. Biederman [this message]
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=87txghm1qw.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