On Thu, Feb 8, 2018 at 1:36 PM, Chuck Lever <chucklever@xxxxxxxxx> wrote: > > >> On Feb 8, 2018, at 1:07 PM, Chuck Lever <chucklever@xxxxxxxxx> wrote: >> >> 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 As a first step, Steve has committed patches that address bugzilla 320. This makes libtirpc avoid allocating reserved ports for RPC service listeners and long-running clients that request a dynamically assigned port. svc_tli_create(3) and clnt_tli_create(3) were wrong to use bindresvport(3) for this purpose. IMO this addresses the two cases Guillem Jover reported explicitly: rpc.statd's listener, and the rpcbind CALLIT client. mountd on RHEL systems appears to use 20048 (though it can use any dynamically- assigned port) and lockd's service port is assigned by the kernel, so it is typically outside the reserved port range. Even so, I can see that making bindresvport(3) more particular about skipping IANA-assigned ports in the reserved port range might provide additional benefit/relief. I checked with a pal on the Solaris NFS team to see if their user space bindresvport(3) implementation was careful to avoid IANA- assigned ports. He said it does not currently, but they have considered it and probably will consider it again because there are occasional requests for such functionality. The question now is whether to consult /etc/services, a separate blacklist, or both, when trolling for an unused reserved port. It seems easiest to start with /etc/services; then perhaps introduce a blacklist file/directory later if that is desirable. Other opinions? Note that neither of these solutions addresses the largest consumer of dynamically-assigned reserved ports: the kernel NFS client. The only way we have to address that today is the "noresvport" mount option. (We could make that the default for Kerberos mounts). -- "We cannot take our next breath without the exhale." -- Ellen Scott Grable -- 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
