netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).