From: Jonas Bonn <jonas@norrbonn.se>
To: "Mahesh Bandewar (महेश बंडेवार)" <maheshb@google.com>
Cc: nicolas.dichtel@6wind.com, linux-netdev <netdev@vger.kernel.org>,
linux-kernel@vger.kernel.org, David Miller <davem@davemloft.net>
Subject: Re: [PATCH v3 1/6] rtnetlink: allow RTM_SETLINK to reference other namespaces
Date: Fri, 8 Nov 2019 09:20:40 +0100 [thread overview]
Message-ID: <fff51fa7-5c42-7fa7-6208-d911b18bd91e@norrbonn.se> (raw)
In-Reply-To: <CAF2d9jjRLZ07Qx0NJ9fi1iUpHn+qYEJ+cacKgBmeZ2FvZLObEQ@mail.gmail.com>
Hi Mahesh,
On 07/11/2019 21:36, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Thu, Nov 7, 2019 at 5:30 AM Jonas Bonn <jonas@norrbonn.se> wrote:
>>
>>
>> + /* A hack to preserve kernel<->userspace interface.
>> + * It was previously allowed to pass the IFLA_TARGET_NETNSID
>> + * attribute as a way to _set_ the network namespace. In this
>> + * case, the device interface was assumed to be in the _current_
>> + * namespace.
>> + * If the device cannot be found in the target namespace then we
>> + * assume that the request is to set the device in the current
>> + * namespace and thus we attempt to find the device there.
>> + */
> Could this bypasses the ns_capable() check? i.e. if the target is
> "foo" but your current ns is bar. The process may be "capable" is foo
> but the interface is not found in foo but present in bar and ends up
> modifying it (especially when you are not capable in bar)?
I don't think so. There was never any capable-check for the "current"
namespace so there's no change in that regard.
I do think there is an issue with this hack that I can't see any
workaround for. If the user specifies an interface (by name or index)
for another namespace that doesn't exist, there's a potential problem if
that name/index happens to exist in the "current" namespace. In that
case, one many end up inadvertently modifying the interface in the
current namespace. I don't see how to avoid that while maintaining the
backwards compatibility.
My absolute preference would be to drop this compat-hack altogether.
iproute2 doesn't use a bare TARGET_NETNSID in this manner (for changing
namespaces) and I didn't find any other users by a quick search of other
prominent Netlink users: systemd, network-manager, connman. This
compat-hack is there for the _potential ab-user_ of the interface, not
for any known such.
>
>> + if (!dev && tgt_net) {
>> + net = sock_net(skb->sk);
>> + if (ifm->ifi_index > 0)
>> + dev = __dev_get_by_index(net, ifm->ifi_index);
>> + else if (tb[IFLA_IFNAME])
>> + dev = __dev_get_by_name(net, ifname);
>> + }
/Jonas
next prev parent reply other threads:[~2019-11-08 8:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-07 13:27 [PATCH v3 0/6] Add namespace awareness to Netlink methods Jonas Bonn
2019-11-07 13:27 ` [PATCH v3 1/6] rtnetlink: allow RTM_SETLINK to reference other namespaces Jonas Bonn
2019-11-07 20:36 ` Mahesh Bandewar (महेश बंडेवार)
2019-11-08 8:20 ` Jonas Bonn [this message]
2019-11-08 18:55 ` Mahesh Bandewar (महेश बंडेवार)
2019-11-09 14:17 ` Jonas Bonn
2019-11-12 1:29 ` Mahesh Bandewar (महेश बंडेवार)
2019-11-07 13:27 ` [PATCH v3 2/6] rtnetlink: skip namespace change if already effect Jonas Bonn
2019-11-07 13:27 ` [PATCH v3 3/6] rtnetlink: allow RTM_NEWLINK to act upon interfaces in arbitrary namespaces Jonas Bonn
2019-11-07 13:27 ` [PATCH v3 4/6] net: ipv4: allow setting address on interface outside current namespace Jonas Bonn
2019-11-07 13:27 ` [PATCH v3 5/6] net: namespace: allow setting NSIDs " Jonas Bonn
2019-11-07 13:27 ` [PATCH v3 6/6] net: ipv6: allow setting address on interface " Jonas Bonn
2019-11-07 13:56 ` [PATCH v3 1/1] " Jonas Bonn
2019-11-07 16:58 ` Nicolas Dichtel
2019-11-07 18:37 ` [PATCH v3 0/6] Add namespace awareness to Netlink methods David Miller
2019-11-07 20:40 ` Mahesh Bandewar (महेश बंडेवार)
2019-11-07 21:11 ` David Ahern
2019-11-08 15:36 ` Jonas Bonn
2019-11-08 18:59 ` Mahesh Bandewar (महेश बंडेवार)
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=fff51fa7-5c42-7fa7-6208-d911b18bd91e@norrbonn.se \
--to=jonas@norrbonn.se \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=maheshb@google.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).