Re: [PATCH net-next 0/3 V1] rtnetlink: enable IFLA_IF_NETNSID for RTM_{DEL,SET}LINK

[Nicolas Dichtel]

Le 24/01/2018 Ã 17:35, Jiri Benc a ÃcritÂ:
> On Wed, 24 Jan 2018 16:24:34 +0100, Nicolas Dichtel wrote:
>> I wonder if it would be possible to do something in the netlink framework, like
>> NETLINK_LISTEN_ALL_NSID.
>> Having some ancillary data at the netlink socket level and a function like
>> nlsock_net() (instead of sock_net()) to get the corresponding netns.
>> With that, it would be possible, in a generci way, to support this feature for
>> all netlink family.
> 
> I'm not sure it's worth the effort to do that in the framework. You'll
> need modifications all the way down to the code that generates the
> attributes anyway.
> 
> It's not enough to just specify that the operation should be done on a
> different netns and hide that from the handlers. Take for example the
> existing RTM_GETLINK. Let's say it's executed from within ns_a and
> targeted to ns_b (thus IFLA_IF_NETNSID = netnsid of ns_b). Now, if
> there's a veth interface in ns_b whose other end is in ns_c, there will
> be IFLA_LINK_NETNSID attribute in the response. But the value has to be
> netnsid of ns_c as seen from *ns_a*. If you just pretended to switch to
> ns_b before invoking rtnl_getlink, it would be netnsid of ns_c as seen
> from ns_b which would be wrong.
Hmm, I don't agree. For me, it would be the correct answer. If user has a socket
in ns_a and targets a RTM_GETLINK in ns_b, the answer he gets should be like if
it was done in ns_b.
This is already the case with messages received with NETLINK_LISTEN_ALL_NSID,
there is no reason to do something different.


Regards,
Nicolas