Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)

[Nicolas Dichtel <nicolas.dichtel@6wind.com>]

Le 15/10/2013 22:34, Eric W. Biederman a écrit :
> 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.
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)?