Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1492090ybx; Thu, 7 Nov 2019 12:38:45 -0800 (PST) X-Google-Smtp-Source: APXvYqyhwsBaLSgyj9TSVSkpWDAXm7+ZkWdWqVBtitrrNQOTf4EDq2Cmbcl7iuSZXaPT5HmoD6z3 X-Received: by 2002:aa7:c943:: with SMTP id h3mr5836495edt.207.1573159125854; Thu, 07 Nov 2019 12:38:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573159125; cv=none; d=google.com; s=arc-20160816; b=xq8BS1yrex7rQT7LFjDN5OEKYt1ZVGRVFR1UmvCS3U4RSBspm8CIeuqnGZ9aEr5S+w 5pwvW0q/+9OEJ1ubU/77HDqNZoIj8rAuwWorwqBkMaM/4i9czppq9kZanaaS4MbY0YiN ikzEYirNu43rEnCaBhQrbdEMjCbmL8gyRWp6sBRF+COQ4KQ6wDxsdsjob7tllwWTDpLJ wH04SWofrBLavHSXqP1wgKFerltliBBw+dHMs7FvT8Z1gR3a++k39q2W53yKCvBjr/Dx zrpf5lDqYw36Q3WoyK8g6ec1oke8+opsmKwEGwtr0V0nWAZ309AsnEsfOZAX5uFKrqZa kLLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=TP2gfIB44smTv89rJyokmz9BkOyIn2LvUmWAiBH1d+E=; b=D3G4Iwzkb07KIKsYD9c6LAxebaFY0ZLuk7VEpP8Zk6q8MQ8zR77GD1urBKIJMNb2nc NdpqKcNUw2rAz6SgR2rq9mGH1s+AHo8lqMfcviAm5C2U95Dviy+e/GNwuBX8NXO6vF2T shng/pDyRdGgjxYlI3foC+Dtd9P/YW9WFfp2+d6VAi1VVn+ct6qtnV7NeCofl6UiI77D DrAVEChp8AXmWQLYTkecA3qjg05GbDoqHoMjPlOvooLYXJof4zvlLC3kq5kySV1VhNLs QxGtp0C5C21wmVrVdysU0HZp28bK1pOBHvwV/j5bOZxr4u8Eb1K6w0awfWVzyzwYfsxj nIsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=umWywYcP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id oz10si2145211ejb.163.2019.11.07.12.38.21; Thu, 07 Nov 2019 12:38:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=umWywYcP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726943AbfKGUhO (ORCPT + 99 others); Thu, 7 Nov 2019 15:37:14 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:50817 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725906AbfKGUhL (ORCPT ); Thu, 7 Nov 2019 15:37:11 -0500 Received: by mail-wm1-f67.google.com with SMTP id l17so3154636wmh.0 for ; Thu, 07 Nov 2019 12:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TP2gfIB44smTv89rJyokmz9BkOyIn2LvUmWAiBH1d+E=; b=umWywYcPK3FTy94uZjfwZArOxYGDSgRVzysG9MhLIphBRp4npsSGJ8NhBmJ12FkTY/ L2UOnAS0ObAT1aqj87ue1joW7soLQsnkIHtpXyx3/qXUAwfANwh80RpLDaUROptOYb4v gSjbCuS1S21wE5AfwBQD9fnNyo6eBD1QNbZxLXwSe73fhlUxeftUzek8uLeRdJ5gbxxX xQGi7jifnf/uOK5IixDVewN3GPKyVTT3S00PymXSl9B0h+C+tjPfaVUh6ehSLXLQTidS u128ewtd6//6/798cB7kY/pBZyB1K2mXHjsASpGDjJgt8baWaxV9vad1XGAvDPITfyFX fbjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TP2gfIB44smTv89rJyokmz9BkOyIn2LvUmWAiBH1d+E=; b=cddGqgwJxofezlPtjSVdUP9FIA6mVDo5JZc0S8avea9l/AqOL0xjOOdGeBdOT/DAxZ f/SUfwkjvxhJV/O82xRp6WzVIkIfH+5Iy10MIWsVGRFxSSdpGz9I8vA2UZWNkIz5/U1t XjBcvoRgGMkstwWKcUXpZw7MLHq8XrQJpg4ZjEcjfOhxb1QA8qqUgRvK0uWOD/YHF6cV vd1D0DJpI5Tr6SVh1q7zDwxPbxuJxWSn8blgJspfhwp6hF6ozFZcOOAmV5ShW+Qwib75 60GaEa3eQgrpcyUPTVYD49bfx8u3h7tngwlYZpaOJBqZgmLHhsX3KEYgjuEA0btDw0ka M8zQ== X-Gm-Message-State: APjAAAX4w+SPrk6O4f75/powfnN+lVpVCNz2GRO8JWH3S/cKgRIwIm7e rckLgkYdeWTcoX02xP/yf9CoRZcDj59RzBewl+hvHw== X-Received: by 2002:a1c:a9cb:: with SMTP id s194mr5135816wme.92.1573159027084; Thu, 07 Nov 2019 12:37:07 -0800 (PST) MIME-Version: 1.0 References: <20191107132755.8517-1-jonas@norrbonn.se> <20191107132755.8517-2-jonas@norrbonn.se> In-Reply-To: <20191107132755.8517-2-jonas@norrbonn.se> From: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= Date: Thu, 7 Nov 2019 12:36:50 -0800 Message-ID: Subject: Re: [PATCH v3 1/6] rtnetlink: allow RTM_SETLINK to reference other namespaces To: Jonas Bonn Cc: nicolas.dichtel@6wind.com, linux-netdev , linux-kernel@vger.kernel.org, David Miller Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 7, 2019 at 5:30 AM Jonas Bonn wrote: > > Netlink currently has partial support for acting on interfaces outside > the current namespace. This patch extends RTM_SETLINK with this > functionality. > > The current implementation has an unfortunate semantic ambiguity in the > IFLA_TARGET_NETNSID attribute. For setting the interface namespace, one > may pass the IFLA_TARGET_NETNSID attribute with the namespace to move the > interface to. This conflicts with the meaning of this attribute for all > other methods where IFLA_TARGET_NETNSID identifies the namespace in > which to search for the interface to act upon: the pair (namespace, > ifindex) is generally given by (IFLA_TARGET_NETNSID, ifi->ifi_index). > > In order to change the namespace of an interface outside the current > namespace, we would need to specify both an IFLA_TARGET_NETNSID > attribute and a namespace to move to using IFLA_NET_NS_[PID|FD]. This is > currently now allowed as only one of these three flags may be specified. > > This patch loosens the restrictions a bit but tries to maintain > compatibility with the previous behaviour: > i) IFLA_TARGET_NETNSID may be passed together with one of > IFLA_NET_NS_[PID|FD] > ii) IFLA_TARGET_NETNSID is primarily defined to be the namespace in > which to find the interface to act upon > iii) In order to maintain backwards compatibility, if the device is not > found in the specified namespace, we also look for it in the current > namespace > iv) If only IFLA_TARGET_NETNSID is given, the device is still moved to > that namespace, as before; and, as before, IFLA_NET_NS_[PID|FD] take > precedence as namespace selectors > > Ideally, IFLA_TARGET_NETNSID would only ever have been used to select the > namespace of the device to act upon. A separate flag, IFLA_NET_NS_ID > would have been made available for changing namespaces > > Signed-off-by: Jonas Bonn > Acked-by: Nicolas Dichtel > --- > net/core/rtnetlink.c | 37 ++++++++++++++++++++++++++++++------- > 1 file changed, 30 insertions(+), 7 deletions(-) > > diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c > index c81cd80114d9..aa3924c9813c 100644 > --- a/net/core/rtnetlink.c > +++ b/net/core/rtnetlink.c > @@ -2109,13 +2109,7 @@ static int rtnl_ensure_unique_netns(struct nlattr *tb[], > return -EOPNOTSUPP; > } > > - if (tb[IFLA_TARGET_NETNSID] && (tb[IFLA_NET_NS_PID] || tb[IFLA_NET_NS_FD])) > - goto invalid_attr; > - > - if (tb[IFLA_NET_NS_PID] && (tb[IFLA_TARGET_NETNSID] || tb[IFLA_NET_NS_FD])) > - goto invalid_attr; > - > - if (tb[IFLA_NET_NS_FD] && (tb[IFLA_TARGET_NETNSID] || tb[IFLA_NET_NS_PID])) > + if (tb[IFLA_NET_NS_PID] && tb[IFLA_NET_NS_FD]) > goto invalid_attr; > > return 0; > @@ -2727,6 +2721,7 @@ static int rtnl_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, > struct netlink_ext_ack *extack) > { > struct net *net = sock_net(skb->sk); > + struct net *tgt_net = NULL; > struct ifinfomsg *ifm; > struct net_device *dev; > int err; > @@ -2742,6 +2737,15 @@ static int rtnl_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, > if (err < 0) > goto errout; > > + if (tb[IFLA_TARGET_NETNSID]) { > + s32 netnsid = nla_get_s32(tb[IFLA_TARGET_NETNSID]); > + > + tgt_net = rtnl_get_net_ns_capable(NETLINK_CB(skb).sk, netnsid); > + if (IS_ERR(net)) > + return PTR_ERR(net); > + net = tgt_net; > + } > + > if (tb[IFLA_IFNAME]) > nla_strlcpy(ifname, tb[IFLA_IFNAME], IFNAMSIZ); > else > @@ -2756,6 +2760,23 @@ static int rtnl_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, > else > goto errout; > > + /* 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)? > + 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); > + } > + > if (dev == NULL) { > err = -ENODEV; > goto errout; > @@ -2763,6 +2784,8 @@ static int rtnl_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, > > err = do_setlink(skb, dev, ifm, extack, tb, ifname, 0); > errout: > + if (tgt_net) > + put_net(tgt_net); > return err; > } > > -- > 2.20.1 >