(Christian, I'm adding back the netdev list, there's no reason not to
have the discussion in open.)
On Tue, 23 Jan 2018 12:42:19 +0100, Christian Brauner wrote:
> Thanks for the comments and discussion. Sorry, for not going through the
> list but I just have a quick question that doesn't deserve to spam the
> whole netdev list. :) I have written another set of patches that would
> add support for IFLA_IF_NETNSID to RTM_{N,S}ETLINK and friends which I
> planned to send out after the pid and fd ones. Would you be interested
> in those if I sent them out over the next week?
Yes, please CC me. I will have limited time next week (whole day
meetings for the most of the week) but I'll try to review.
In general, I see value in adding netnsid support to setlink, newlink
and dellink. It's a bit of minefield, though. Look for and be sure to
resolve:
- Backwards compatibility with old kernels. Old kernels will ignore
the IFLA_IF_NETNSID attribute that is unknown to them. And it's
certainly undesirable for an application to attempt to set/create an
interface in a given netns and instead the kernel sets/creates an
interface in the current netns.
In 79e1ad148c844, I put into place means to handle that: any kernel
that understands IFLA_IF_NETNSID but does not support
setlink/newlink/dellink will return -EOPNOTSUPP. This reduces the
problem to detecting whether the kernel understands IFLA_IF_NETNSID.
This can be done by invoking getlink with IFLA_IF_NETNSID and
looking whether the reply contains IFLA_IF_NETNSID.
The current getlink calls are also limited to CAP_NET_ADMIN in the
*target* netns. If/when this is relaxed in the future, we still need
to stay backwards compatible.
So, the application needs to do this:
1. call RTM_GETLINK with IFLA_IF_NETNSID on lo (or do a dump)
2. if getting EACCESS, assume IFLA_IF_NETNSID is not supported =>
fall back to other means
2. if the reply does not contain IFLA_IF_NETNSID, the kernel does not
support IFLA_IF_NETNSID => fall back to other means
3. try RTM_SETLINK/NEWLINK/DELLINK and check for EOPNOTSUPP => fall
back to other means
What is important for your kernel patches is to not break this. If
you implement only partial support for some of the operation, think
about the future extensibility. Applications have to be able to
reliably detect what is supported on the running kernel, regardless
of the kernel version.
- Access rights. This is security sensitive stuff. I took the big
hammer and limited everything to CAP_NET_ADMIN in the target netns.
If you want to relax this, be sure to get review from people involved
in name space security.
Jiri
