From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [193.142.43.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82AC228E7 for ; Tue, 9 Aug 2022 10:55:32 +0000 (UTC) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1oLMQ7-0004Gj-NV; Tue, 09 Aug 2022 12:25:07 +0200 Date: Tue, 9 Aug 2022 12:25:07 +0200 From: Florian Westphal To: Mat Martineau Cc: Thomas Haller , mptcp@lists.linux.dev, Paolo Abeni , Florian Westphal , Matthieu Baerts Subject: Re: [PATCH] mptcp: allow priviledged operations from user namespaces Message-ID: <20220809102507.GA13671@breakpoint.cc> References: <20220805115020.525181-1-thaller@redhat.com> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Mat Martineau wrote: > On Fri, 5 Aug 2022, Thomas Haller wrote: > > > GENL_ADMIN_PERM checks that the user has CAP_NET_ADMIN in the initial > > namespace by calling netlink_capable(). Instead, use GENL_UNS_ADMIN_PERM > > which uses netlink_ns_capable(). This checks that the caller has > > CAP_NET_ADMIN in the current user namespace. > > > > See also commit 4a92602aa1cd ('openvswitch: allow management from inside > > user namespaces') which introduced this mechanism. See also commit > > 5617c6cd6f84 ('nl80211: Allow privileged operations from user > > namespaces'), which introduced this for nl80211. > > > > Signed-off-by: Thomas Haller > > Hi Thomas - > > Thanks for the patch! This does seem like a good idea to me (and it seems to > work ok with our MPTCP tests), but I'd like to get some more community input > before merging (Paolo/Florian?). Looks good to me, I don't see any places where we'd accept e.g. a token from a different netns. mptcp_nl_cmd_add_addr should probably be changed to use GFP_KERNEL_ACCOUNT so that the added entries can be limited via memcg. mptcp_userspace_pm_append_new_local_addr() helper needs a bit of rework for that, but I don't think this has do be done right away. Personally I'd go for -next though.