On 02/02/2018 10:22 AM, Chuck Lever wrote: > > >> 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. 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 > > > -- 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
