I took sometime to verify this crusty code actually works... It does. On 01/31/2018 03:09 PM, Chuck Lever wrote: > >>> >>> We should change rpcbind to retain CAP_NET_BIND_SERVICE, so that >>> it doesn't have to hold onto that port indefinitely. It should >>> be able to bind to an outgoing privileged port whenever it needs >>> one. You suggesting we do something similar to nsm_clear_capabilities()? >> Or we just avoid know ports like sm-notify does. > > statd, you mean. It should also retain CAP_NET_BIND_SERVICE instead > of what it does now, IMO. Well I was talking about the code in sm-notify.c but yes statd does make the same call to getservbyport(). > > Note that in both of these cases, that long-lived port is never going > to be used, going forward: > > - no one uses the rpcbind port-forward service that I know of Has any ever use it?? Why did it even exist?? > > - NLM is going out of style Not fast enough! ;-) > > If we can make these two cases on-demand instead, so much the better, > I say. As Mr. Talpey pointed out recently, the only long-lived > privileged ports we should see on Linux are well-known service > listeners, not outgoing ports. I guess this the patch Scott has posted... After a quick look there appears to be a lot changed which is bit worrisome... > > A fix for rpcbind might be to add a cmd-line flag to enable the > rpcbind forwarding service, and have the service default to disabled. I would rather have it auto-magically work ;-) > 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 :-( steved. -- 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
