Bug #3807
open
rpc_clnt_create uses udp when tcp is requested
0%
Description
I ran into this while trying to use showmount -e through a firewall which allows sunrpc/tcp but not udp.
Apparently clnt_create() called with nettype="tcp" will create a rpc client for UDP instead. There's even a comment to that effect in the source [1] so maybe someone intended this to be a feature, but that just seems wrong to me. At the very least it's undocumented behavior.
[1]: https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libnsl/rpc/rpcb_clnt.c#L741
Updated by Yuri Pankov almost 10 years ago
Quoting the function comment:
The algorithm used: If the transports is TCP or UDP, it first tries version 2 (portmap), 4 and then 3 (svr4). This order should be changed in the next OS release to 4, 2 and 3.
Looks like the "next OS release" never happened.
Updated by Gary Mills about 9 years ago
- Status changed from New to Feedback
- Assignee set to Gary Mills
I'll see what I can do with this one.
Updated by Gary Mills about 9 years ago
Blocking UDP in a firewall likely will never work. The reason is that an RPC client first has to send a query to the remote rpcbind server to obtain the port number on which the server is listening. Only then will it send a second query to the actual server. Even if TCP is used for the second, it will likely use UDP for the first query. At the very least, you will have to allow RPC or UDP queries to rpcbind (port 111).
Updated by Marcel Telka about 9 years ago
rpcbind listens on both transports: UDP and TCP. It is client's decision what transport it uses/tries.
Updated by Gary Mills about 9 years ago
Yes, the rpcbind server listens on both transports, but the client application does not get to choose which one. The clnt_create() function can only be given the transport that's used to contact the remote service. It may listen on only one transport. It's quite possible then that the client application specifies TCP, but that UDP is used first to contact the remote rpcbind server. In fact, the __rpcb_findaddr_timed() function in rpcb_clnt.c selects UDP in two places, one for rpcbind version 4 and one for version 2. I'm assuming it does this for efficiency reasons. It doesn't do this for version 3 because there's no mechanism for doing it.
Updated by Gary Mills about 9 years ago
Since contacting the rpcbind service with UDP before contacting the destination service with TCP is normal behavior, I'm recommending that this bug report be closed.
Updated by Marcel Telka about 9 years ago
I think there is a bug and I believe the client should try more than UDP only when it is contacting the rpcbind.