> On Feb 8, 2018, at 1:07 PM, Chuck Lever <chucklever@xxxxxxxxx> wrote: > > On Fri, Jan 12, 2018 at 2:19 PM, Tom Talpey <tom@xxxxxxxxxx> wrote: >> On 1/12/2018 1:41 PM, Guillem Jover wrote: >>> >>> On Thu, 2018-01-11 at 10:18:46 -0500, Steve Dickson wrote: >>>> >>>> Overall I think this makes sense, but this eliminates 240 privilege >>>> ports and worried we would run out of port (due to them in TIME_WAIT) >>>> during a v3 mount storms. A port goes into TIME_WAIT after a v3 mount >>>> is done... But on the other hand v3 is no longer the default and >>>> there are 784 available ports.... Hopefully that is enough. >>> >>> >>> Hmm, those numbers do not match my own. bindresvport() uses the port >>> range between 512 and 1023 inclusive. On my Debian stable (stretch) >> >> >> Properly speaking, no service should be binding to any port but the >> one it is assigned to. This includes 0-1023 as well as 1024-49151. >> >> https://tools.ietf.org/html/rfc6335 >> >> See last quoted sentence from: >> >> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml >> >>>> Service names are assigned on a first-come, first-served process, as >>>> documented in [RFC6335]. >>>> >>>> Port numbers are assigned in various ways, based on three ranges: System >>>> Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private >>>> Ports (49152-65535); the difference uses of these ranges is described in >>>> [RFC6335]. According to Section 8.1.2 of [RFC6335], System Ports are >>>> assigned by the "IETF Review" or "IESG Approval" procedures described in >>>> [RFC8126]. User Ports are assigned by IANA using the "IETF Review" process, >>>> the "IESG Approval" process, or the "Expert Review" process, as per >>>> [RFC6335]. Dynamic Ports are not assigned. >>>> >>>> The registration procedures for service names and port numbers are >>>> described in [RFC6335]. >>>> >>>> Assigned ports both System and User ports SHOULD NOT be used without >>>> or prior to IANA registration. >> >> >> Tom. > > At Steve's request, I've filed a bug against libtirpc: > > https://bugzilla.linux-nfs.org/show_bug.cgi?id=320 > > to document the issue and the rationales for alternate solutions. > > I'm fairly confident that bindresvport(3) is never necessary for > svc_tli_create(3). It is arguably also not appropriate for > clnt_tli_create(3). Therefore IMO it should be removed from those code > paths. That by itself would provide some relief and would eliminate > the need to alter the current bindresvport(3) implementation (say, by > introducing a blacklisting mechanism). > > As Tom mentioned above, RFC 6335 describes a port range that will > never interfere with service ports allocated by IANA. This range is > known as the Dynamic or Private port range (49152 - 65535). On my > systems, bind(3) already frequently allocates from the Dynamic port > range purely by chance. > > To completely prevent the accidental allocation of a well-known > service port, a special internal wrapper for the bind(3) system call > (similar to bindresvport(3)) can be constructed for libtirpc that > allocates only from the Dynamic port range whenever a caller does not > specify a port, making libtirpc adhere to the Best Common Practices > outlined in RFC 6335, and thereby closing this window for user space > RPC services completely. > > A more thorough solution IMO would be to fix up the bind(3) system > call to allocate only from the Dynamic port range whenever a caller > does not specify a port. This would take care of not only user space > RPC services but of all dynamically allocated ports on the system, > including ports dynamically allocated in the kernel. Replace "bind(3)" with "bind(2)" throughout. Oops. -- Chuck Lever chucklever@xxxxxxxxx -- 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
