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 1CEB23C35 for ; Tue, 9 Aug 2022 11:16:26 +0000 (UTC) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1oLNDk-0004ra-ET; Tue, 09 Aug 2022 13:16:24 +0200 Date: Tue, 9 Aug 2022 13:16:24 +0200 From: Florian Westphal To: Florian Westphal Cc: Mat Martineau , Thomas Haller , mptcp@lists.linux.dev, Paolo Abeni , Matthieu Baerts Subject: Re: [PATCH] mptcp: allow priviledged operations from user namespaces Message-ID: <20220809111624.GA18587@breakpoint.cc> References: <20220805115020.525181-1-thaller@redhat.com> <20220809102507.GA13671@breakpoint.cc> 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: <20220809102507.GA13671@breakpoint.cc> User-Agent: Mutt/1.10.1 (2018-07-13) Florian Westphal wrote: > 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. Actually its fine; the allocation is accounted vs the socket. mptcp_nl_cmd_add_addr has the only "permanent" kmalloc that I can see.