> 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? >>> 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. 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
