Package: rpcbind Version: 0.2.0-8 Severity: normal Dear Maintainer,
I just upgraded a NIS server from Squeeze to Wheezy, hence from portmap to rpcbind. Yes, I know it's 2017 and there's Jessie, if not Stretch :). Some of that server's clients stopped being able to find it with ypbind's broadcast. ypbind appears to send a subnet broadcast CALLIT request to port 111 for the YPSERV program's DOMAIN_NON_ACK procedure. These clients were firewalled. They had a hole allowing udp traffic from port 111. portmap's replies were coming from port 111. All was good. rpcbind's replies come from another reserved udp port. That doesn't have a firewall hole. All is no longer good. This port is picked at seeming random when rpcbind starts. The variation makes firewalling difficult. I've looked at the source and I'm confident that it's behaving as designed. The design just seems... a little unfortunate. It seems to predate the current upstream, which started with: http://git.linux-nfs.org/?p=steved/rpcbind.git;a=blob;f=src/rpcb_svc_com.c;hb=f4aea95069461d06bd8a13e189e1a77e9ca03d75 Indeed, I see the problem looks to be there in Wietse Venema's rpcbind_2.1.tar.gz at: http://ftp.porcupine.org/pub/security/index.html But not in his portmap_5beta.tar.gz. I conclude that Sun bequeathed it to us like this. I wonder if the reason for all that extra code was to remove the fork() that the portmap implementation used. I doubt I could persuade anyone to change the design even if I tried. I raise this, then, just to document the issue for the next poor sap to be tripped up by it. Upstream's bug database: https://sourceforge.net/p/rpcbind/bugs/?source=navbar ... seemed more moribund than Debian's. The extra open udp and udp6 ports might have caused the intermittent failures culminating in an expression of security concern at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650425#25 ... and the puzzlement at: https://stackoverflow.com/questions/35783145/why-is-rpcbind-opening-a-new-and-different-port-anytime-its-restarted When I found: https://www.illumos.org/issues/4483: rpcbind: Reply for remote calls comes from incorrect UDP port I thought someone else had already fixed it. But having plowed through the large patch there, I don't see how it would fix that. Perhaps I missed something. Our ref: D131248. -- System Information: Debian Release: 7.4 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rpcbind depends on: ii initscripts 2.88dsf-41+deb7u1 ii insserv 1.14.0-5 ii libc6 2.13-38+deb7u11 ii libtirpc1 0.2.2-5 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian8+deb7u1 rpcbind recommends no packages. rpcbind suggests no packages. -- debconf-show failed
