On 04/10/2018 06:43 PM, Chuck Lever wrote: > > >> On Apr 10, 2018, at 9:21 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >> >> On 04/09/2018 05:11 PM, Chuck Lever wrote: >>> >>>> On Apr 9, 2018, at 2:04 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >>>> >>>> On 04/09/2018 02:40 PM, Chuck Lever wrote: >>>>> I'm going to firmly object on this one, unless you have >>>>> a clearly documented breakage that requires the legacy >>>>> server API to use bindresvport(3). >>>> Here is what the man page says "If the socket is not bound to a >>>> local TCP port, then this routine binds it to an arbitrary port." >>>> >>>> The point being it also does not talk about creating a >>>> listening connection either... Changing the (undocumented) >>>> API like this can cause nothing but problems... IMHO... >>> >>> Please show me one specific breakage that will result >>> in removing bindresvport from svc_com_create. Just one, >>> and I promise I will crawl back into my hole. >> The patch also restores the listen() which is >> something I can see a server apps depending on. > > I'm not clear there's a problem there. Did you find > that svc_tli_create() was not already doing a listen? yeah I didn't see that... > > >>>> Basically, not making this change will cause a fork with >>>> all the major distros since it very import for them to be >>>> backward compatible esp in enterprise worlds. >>> >>> That sounds like an overstatement. Who claims they won't >>> take libtirpc with an unprivileged svc_com_create? I would >>> really like to understand why. >> I'm just assuming most distros want to be backward compatible >> and not break legacy apps... Maybe I'm wrong... > > Of course they don't want to break legacy apps. I just don't > see any backwards compatibility requirement here: servers > never need a reserved port, they need either a specific port, > or any port. > > Therefore the libtirpc server-side APIs should not use > bindresvport. > > >>>> Upstream not >>>> so much... Who really uses raw upstream bits in a stable >>>> environment... understood... But this brings me to my point. >>>> >>>> What problem is being fixed by changing an 20+ year API? >>> >>> The problem is legacy clients and servers are squatting on >>> ports that are assigned to other network services. These >>> patches mitigate that problem. There is more to be done. >> Any examples of these... The only one I know is rpcbind >> which can be fixed in another ways.... > > Yes, as you and I discussed with Trond, statd can squat > on a reserved port for it's downcall client to lockd. The > fix Trond prefers is for this downcall service to use an > AF_LOCAL socket instead. But it is careful not to used any ports in /etc/services steved. > > We should also update bindresvport(3) to do more to avoid > selecting ports that appear in /etc/services. This will > cover user apps that use the RPC library API. > > > -- > 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
