Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:32946 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751737AbeBBQ1x (ORCPT ); Fri, 2 Feb 2018 11:27:53 -0500 Subject: Re: Question about random UDP port on rpcbind 0.2.3 To: Chuck Lever Cc: Scott Mayhew , Naruto Nguyen , Linux NFS Mailing List References: <47c040cf-d0a8-eb42-a276-9bc2e264ff6e@RedHat.com> <66B30606-7AFE-43C8-8A51-5D031F9D744B@oracle.com> <27ec9304-5763-9885-b3c9-246c395e6986@RedHat.com> <1165B44B-0D40-42FF-94EE-9B852AD4C8FA@oracle.com> <20180201152918.am75vfq776vtj3i3@tonberry.usersys.redhat.com> <11614659-a3c9-b3c9-73e7-886e1f3d50a4@RedHat.com> From: Steve Dickson Message-ID: <2d7a93c3-815f-9f96-c672-da9c7d777bd0@RedHat.com> Date: Fri, 2 Feb 2018 11:27:51 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On 02/02/2018 10:22 AM, Chuck Lever wrote: > > >> On Feb 2, 2018, at 10:06 AM, Steve Dickson wrote: >> >> >> >> On 02/01/2018 10:29 AM, Scott Mayhew wrote: >>> >>> This patch should take care of making rpcbind set up the remote call >>> port on demand. I don't have a whole lot of ways to test it though... >>> just 'rpcinfo -b' and a handful of one-off programs I wrote a while back >>> trying to mess with the CALLIT/INDIRECT/BCAST procedures. >> This is where I spent my afternoon yesterday... figuring >> out a way to test this code. rpc_call() is my new BFF! > > Thanks! > > >>> I'd still need to add the stuff to retain CAP_NET_BIND_SERVICE. >> I think we need to do what nsm_clear_capabilities() does. > > Agree, that's exactly what is needed to allow bindresvport > on demand, if rpcbind (or statd) does not run as root. With Fedora, rpcbind runs as 'rpc' and statd runs as 'rpcuser' So changing the capabilities would have to happen early on. > > The only issue I see is that some distros might not have > libcap. There is plenty of infrastructure in nsm/file.c that > deals with the "libcap absent" case, which makes me wonder. IDK... Fedora has it... > > >>> I also like the idea of leaving this off by default and adding a >>> command-line flag to enable it because I'm also not sure if anyone >>> actually uses it... not to mention there's been at least one CVE in the >>> past that exploited it (CVE-2015-7236, not sure if there are others). >> I'm not a fan of this idea... I think on demand is a better way >> to go... but what do I know?? ;-) >> >>> I'm not sure why rpcbind would list an outgoing port in it's portmap >>> menu. Are you sure that this is the forwarding reflector port? >>> >> Yes... the listening fd is created by create_rmtcall_fd() >> This is not the first time people have complained about >> rpbind's rogue listening port :-( > > Hrm. If this is indeed a listening port, on demand bindresvport > won't help (on demand will only fix outgoing ports). I had > assumed there was a long-lived reserved port that was being > used just for outgoing RPCs, just like statd. No. create_rmtcall_fd() just calls svc_tli_create() which does the bindresvport()... > > Does that listening port have to be in the privileged port range? Taking a quick look at mountd and statd I didn't see any code requiring a privileged port... Maybe to call into the kernel? steved. > > > -- > Chuck Lever > > >