> On Feb 6, 2018, at 11:35 PM, NeilBrown <neilb@xxxxxxxx> wrote: > > On Mon, Feb 05 2018, Tom Talpey wrote: > >> On 2/5/2018 12:02 PM, Chuck Lever wrote: >>> Heya Steve- >>> >>>> On Feb 5, 2018, at 11:36 AM, Steve Dickson <steved@xxxxxxxxxx> wrote: >>>> >>>> Over the weekend I did some experimenting with >>>> the remote call code in rpcbind. The code does >>>> functionally work but is very antiquated when >>>> it comes to the latest NFS versions. >>>> >>>> Since only UDP sockets are used to do remote calls >>>> using the documented interfaces pmap_rmtcall() and callrpc() >>>> calls to NFS will fail (actual times out) since UDP is no >>>> longer supported. >>>> >>>> The undocumented interface rpc_call() can be used to >>>> call into NFS since the protocol can specified, which >>>> also means the PMAPPROC_CALLIT protocol is not used. >>>> >>>> It turns out privilege port are not needed to make >>>> remote calls, at least with my testing. >>> >>> It's not quite clear what you are claiming here, but >>> I'm guessing that what you demonstrated is that the >>> CALLIT _listener_ does not have to be privileged? > > rpcbind listens for CALLIT on port 111. Right, my bad. CALLIT is an RPC procedure, not an RPC program. > Listening on some other port wouldn't ever get the messges... Then we still do not understand why rpcbind is opening and registering a second listener port. I can't think of any reason it should do this other than that there is a bug. >>> >>> I claim that is true for all RPC listeners. >> >> >> Why in the world is the remote-call interface even still supported? >> It is and was a mammoth security hole allowing machine impersonation, >> and to my knowledge no actual services or applications depends on >> it. Why not bury it under some compatibility option, default=off?? > > Is "ybind --broadcast" still used? > Even it is it, the port that rpcbind uses to forward the request doesn't > need to be privileged. > > NeilBrown > > >> >> Tom. >> >> >>> >>>> I'm thinking >>>> the only reason privilege ports were being uses was >>>> a side effect of create_rmtcall_fd() calling >>>> svc_tli_create() with an unbound socket. >>> >>> Privileged listener ports are being created because >>> svc_tli_create is using bindresvport when the passed >>> in socket is not already bound. >>> >>> svc_tli_create should use bind instead, and it needs >>> to choose a port higher than 49151. >>> >>> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml >>> >>> >>>> So the following patch simply binds the socket >>>> before calling svc_tli_create() which means a >>>> non-privilege port will be reserved for remote >>>> calls. >>>> >>>> I'm thinking this is the simplest way to >>>> not pollute the privilege port space. >>> >>> This is going in the right direction, but the problem >>> needs to be addressed in svc_tli_create, not in each >>> application that calls svc_tli_create. >>> >>> This is the same issue that Guillem Jover was trying to >>> address by making bindresvport skip well-known ports. >>> >>> In other words: this code in src/svc_generic.c is wrong: >>> >>> 218 /* >>> 219 * If the fd is unbound, try to bind it. >>> 220 */ >>> 221 if (madefd || !__rpc_sockisbound(fd)) { >>> 222 if (bindaddr == NULL) { >>> 223 if (bindresvport(fd, NULL) < 0) { >>> ^^^^^^^^^^^^ >>> >>> 224 memset(&ss, 0, sizeof ss); >>> 225 ss.ss_family = si.si_af; >>> 226 if (bind(fd, (struct sockaddr *)(void *)&ss, >>> 227 (socklen_t)si.si_alen) < 0) { >>> 228 warnx( >>> 229 "svc_tli_create: could not bind to anonymous port"); >>> 230 goto freedata; >>> 231 } >>> 232 } >>> 233 listen(fd, SOMAXCONN); >>> 234 } else { >>> 235 if (bind(fd, >>> 236 (struct sockaddr *)bindaddr->addr.buf, >>> 237 (socklen_t)si.si_alen) < 0) { >>> 238 warnx( >>> 239 "svc_tli_create: could not bind to requested address"); >>> 240 goto freedata; >>> 241 } >>> 242 listen(fd, (int)bindaddr->qlen); >>> 243 } >>> 244 >>> 245 } >>> >>> >>>> Steve Dickson (1): >>>> rmtcalls: Don't use privileged ports for remote calls. >>>> >>>> src/rpcb_svc_com.c | 19 ++++++++++++++++++- >>>> 1 file changed, 18 insertions(+), 1 deletion(-) >>> >>> >>> -- >>> 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 >>> >>> >> -- >> 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 -- 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
