> On Feb 2, 2018, at 10:06 AM, Steve Dickson <SteveD@xxxxxxxxxx> 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. 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. >> 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. Does that listening port have to be in the privileged port range? -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
