Re: rpcbind lingering on IP no longer specified on command line
Date: Thu, 5 Jan 2006 10:31:33 -0500 From: Vivek Khera [EMAIL PROTECTED] Subject: Re: rpcbind lingering on IP no longer specified on command line To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jan 5, 2006, at 6:06 AM, Gavin Atkinson wrote: Can anyone explain why rpcbind will still bind to all tcp interfaces? Although I believe this is a bug, it is actually working as documented: from rpcbind(8): -h bindip Specify specific IP addresses to bind to for UDP requests. Yeah, I noticed that little tiny UDP requests note in the -h docs too. There's no reason to bind to all tcp addresses, and it is causing me heartburn for getting the server certified... Good grief, why not just firewall off the undesired UDP ports and call it good? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Wed, Jan 04, 2006 at 10:46:06PM +0300, Dmitry Morozovsky wrote:
On Wed, 4 Jan 2006, Vivek Khera wrote:
VK I had rpcbind running with on two interfaces like this:
VK
VK rpcbind -h 192.168.100.200 -h 10.0.0.9
VK
VK Now, I changed rpcbind_flags in /etc/rc.conf to just have the first
address,
VK and I restarted rpcbind. the process list from ps shows it is running
like
VK this:
VK
VK rpcbind -h 192.168.100.200
VK
VK Yet nmap on the other address shows rpcbind is still listening on udp
there.
VK How do I stop that?
As I sometimes looked into this, rpcbind (formely portmap) listens on all
described addresses via udp *and* an tcp:*.111 - I tried to dig why is this
but
did not succeed much.
Please test this patch. It's probably a very naive fix, but seems to
work OK.
Ceri
--
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)
Index: rpcbind.8
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.8,v
retrieving revision 1.7
diff -u -r1.7 rpcbind.8
--- rpcbind.8 18 Jan 2005 20:02:43 - 1.7
+++ rpcbind.8 6 Jan 2006 10:35:02 -
@@ -83,7 +83,7 @@
With this option, the name-to-address translation consistency
checks are shown in detail.
.It Fl h Ar bindip
-Specify specific IP addresses to bind to for UDP requests.
+Specify specific IP addresses to bind to.
This option
may be specified multiple times and is typically necessary when running
on a multi-homed host.
@@ -95,14 +95,14 @@
.Dv INADDR_ANY ,
which could lead to problems on a multi-homed host due to
.Nm
-returning a UDP packet from a different IP address than it was
+returning a packet from a different IP address than it was
sent to.
Note that when specifying IP addresses with
.Fl h ,
.Nm
will automatically add
.Li 127.0.0.1
-and if IPv6 is enabled,
+and, if IPv6 is enabled,
.Li ::1
to the list.
.It Fl i
Index: rpcbind.c
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.c,v
retrieving revision 1.14
diff -u -r1.14 rpcbind.c
--- rpcbind.c 7 Nov 2004 04:32:51 - 1.14
+++ rpcbind.c 6 Jan 2006 10:28:10 -
@@ -209,11 +209,11 @@
struct passwd *p;
if((p = getpwnam(RUN_AS)) == NULL) {
- syslog(LOG_ERR, cannot get uid of daemon: %m);
+ syslog(LOG_ERR, cannot get uid of %s: %m, RUN_AS);
exit(1);
}
if (setuid(p-pw_uid) == -1) {
- syslog(LOG_ERR, setuid to daemon failed: %m);
+ syslog(LOG_ERR, setuid to %s failed: %m, RUN_AS);
exit(1);
}
}
@@ -272,7 +272,8 @@
* XXX - using RPC library internal functions. For NC_TPI_CLTS
* we call this later, for each socket we like to bind.
*/
- if (nconf-nc_semantics != NC_TPI_CLTS) {
+ if (nconf-nc_semantics != NC_TPI_CLTS
+ nconf-nc_semantics != NC_TPI_COTS_ORD) {
if ((fd = __rpc_nconf2fd(nconf)) 0) {
int non_fatal = 0;
@@ -308,7 +309,8 @@
hints.ai_socktype = si.si_socktype;
hints.ai_protocol = si.si_proto;
}
- if (nconf-nc_semantics == NC_TPI_CLTS) {
+ if (nconf-nc_semantics == NC_TPI_CLTS ||
+ nconf-nc_semantics == NC_TPI_COTS_ORD) {
/*
* If no hosts were specified, just bind to INADDR_ANY.
Otherwise
* make sure 127.0.0.1 is added to the list.
@@ -348,7 +350,7 @@
hints.ai_flags = AI_NUMERICHOST;
} else {
/*
-* Skip if we have an AF_INET6 adress.
+* Skip if we have an AF_INET6 address.
*/
if (inet_pton(AF_INET6,
hosts[nhostsbak], host_addr) == 1)
@@ -361,7 +363,7 @@
hints.ai_flags = AI_NUMERICHOST;
} else {
/*
-* Skip if we have an AF_INET adress.
+* Skip if we have an AF_INET address.
*/
if (inet_pton(AF_INET, hosts[nhostsbak],
host_addr) == 1)
pgpcOPKf0MNey.pgp
Description: PGP signature
Re: rpcbind lingering on IP no longer specified on command line
On Fri, 6 Jan 2006, Ceri Davies wrote: CD VK I had rpcbind running with on two interfaces like this: CD VK CD VK rpcbind -h 192.168.100.200 -h 10.0.0.9 CD VK CD VK Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, CD VK and I restarted rpcbind. the process list from ps shows it is running like CD VK this: CD VK CD VK rpcbind -h 192.168.100.200 CD VK CD VK Yet nmap on the other address shows rpcbind is still listening on udp there. CD VK How do I stop that? CD CD As I sometimes looked into this, rpcbind (formely portmap) listens on all CD described addresses via udp *and* an tcp:*.111 - I tried to dig why is this but CD did not succeed much. CD CD Please test this patch. It's probably a very naive fix, but seems to CD work OK. Well, two objections: - (obvious and dumb ;): three kinds of changes inside: behaviour, style and typo ;-))) - serious: no way to run on NO_INET6 kernel: [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc 83231 ?? Ss 0:00.00 /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p program vers proto port service 104 tcp111 rpcbind 103 tcp111 rpcbind 102 tcp111 rpcbind 104 udp111 rpcbind 103 udp111 rpcbind 102 udp111 rpcbind 104 local111 rpcbind 103 local111 rpcbind 102 local111 rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# sockstat -4 | grep rpc root rpcbind83332 7 udp4 *:111 *:* root rpcbind83332 8 udp4 *:608 *:* root rpcbind83332 9 tcp4 *:111 *:* Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Jan 6, 2006, at 4:40 AM, James Long wrote: Yeah, I noticed that little tiny UDP requests note in the -h docs too. There's no reason to bind to all tcp addresses, and it is causing me heartburn for getting the server certified... Good grief, why not just firewall off the undesired UDP ports and call it good? I guess we could take that band-aid approach... however, how do you know what port RPC decides to listen on other than the 111 port? It is more or less random. That makes it very difficult to firewall. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Fri, Jan 06, 2006 at 05:35:28PM +0300, Dmitry Morozovsky wrote: On Fri, 6 Jan 2006, Ceri Davies wrote: CD VK I had rpcbind running with on two interfaces like this: CD VK CD VK rpcbind -h 192.168.100.200 -h 10.0.0.9 CD VK CD VK Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, CD VK and I restarted rpcbind. the process list from ps shows it is running like CD VK this: CD VK CD VK rpcbind -h 192.168.100.200 CD VK CD VK Yet nmap on the other address shows rpcbind is still listening on udp there. CD VK How do I stop that? CD CD As I sometimes looked into this, rpcbind (formely portmap) listens on all CD described addresses via udp *and* an tcp:*.111 - I tried to dig why is this but CD did not succeed much. CD CD Please test this patch. It's probably a very naive fix, but seems to CD work OK. Well, two objections: - (obvious and dumb ;): three kinds of changes inside: behaviour, style and typo ;-))) Well yeah, but I figured that didn't matter for now. I disagree that the RUN_AS stuff is style though; the previous hardcoded daemon completely takes away the point of the '#define RUN_AS daemon'. If you are referring to my indentation, again that's just a keep the patch simple thing. Anyway... - serious: no way to run on NO_INET6 kernel: [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc 83231 ?? Ss 0:00.00 /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p program vers proto port service 104 tcp111 rpcbind 103 tcp111 rpcbind 102 tcp111 rpcbind 104 udp111 rpcbind 103 udp111 rpcbind 102 udp111 rpcbind 104 local111 rpcbind 103 local111 rpcbind 102 local111 rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# sockstat -4 | grep rpc root rpcbind83332 7 udp4 *:111 *:* root rpcbind83332 8 udp4 *:608 *:* root rpcbind83332 9 tcp4 *:111 *:* That's more annoying. It's not INET6 though; it's because the local transport is also tpi_cots_ord, so /var/run/rpcbind.sock is not getting created. I'll take another go at this over the weekend. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpXkG0Mwshuf.pgp Description: PGP signature
Re: rpcbind lingering on IP no longer specified on command line
On Fri, 6 Jan 2006, Ceri Davies wrote: CD [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p CD rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success CD CD That's more annoying. It's not INET6 though; it's because the local CD transport is also tpi_cots_ord, so /var/run/rpcbind.sock is not getting CD created. I'll take another go at this over the weekend. Ah yes, I did not check sockets other than tcp4. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Fri, Jan 06, 2006 at 10:22:43AM -0500, Vivek Khera wrote: On Jan 6, 2006, at 4:40 AM, James Long wrote: Yeah, I noticed that little tiny UDP requests note in the -h docs too. There's no reason to bind to all tcp addresses, and it is causing me heartburn for getting the server certified... Good grief, why not just firewall off the undesired UDP ports and call it good? I guess we could take that band-aid approach... however, how do you know what port RPC decides to listen on other than the 111 port? It is more or less random. That makes it very difficult to firewall. P-shaw. If you're enduring heartburn for getting the server certified then firewall off the rpcbind service from unwanted IPs and voila, you get your get your server certified and business goes on. Then you'll have the luxury of time to debug the true problem with rpcbind, and your testing is done behind the privacy of your firewall. As far as unpredictable listening ports opened by rpc, that is exactly why a secure firewall opens only selected ports on selected IPs, and blocks everything else. It doesn't matter if it listens on port X of IP y when your firewall doesn't permit incoming connections on that port and IP in the first place. Jim # sockstat | grep rpcbind root rpcbind11382 5 stream /var/run/rpcbind.sock root rpcbind11382 6 dgram - /var/run/logpriv root rpcbind11382 7 udp4 127.0.0.1:111 *:* root rpcbind11382 8 udp4 192.168.100.200:111 *:* root rpcbind11382 9 udp4 *:664 *:* root rpcbind11382 10 tcp4 *:111 *:* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Wed, 2006-01-04 at 15:44 -0500, Vivek Khera wrote: On Jan 4, 2006, at 2:41 PM, Doug Barton wrote: What does 'sockstat | grep rpcbind' tell you? # sockstat | grep rpcbind root rpcbind11382 5 stream /var/run/rpcbind.sock root rpcbind11382 6 dgram - /var/run/logpriv root rpcbind11382 7 udp4 127.0.0.1:111 *:* root rpcbind11382 8 udp4 192.168.100.200:111 *:* root rpcbind11382 9 udp4 *:664 *:* root rpcbind11382 10 tcp4 *:111 *:* As Dmitry Morozovsky points out, it seems it always listens to tcp *: 111 which seems to be a bad thing. I'm running 6.0-RELEASE-p1. This came up because of some security scans we're having run for some compliance certificates we need... Can anyone explain why rpcbind will still bind to all tcp interfaces? Although I believe this is a bug, it is actually working as documented: from rpcbind(8): -h bindip Specify specific IP addresses to bind to for UDP requests. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Jan 5, 2006, at 6:06 AM, Gavin Atkinson wrote: Can anyone explain why rpcbind will still bind to all tcp interfaces? Although I believe this is a bug, it is actually working as documented: from rpcbind(8): -h bindip Specify specific IP addresses to bind to for UDP requests. Yeah, I noticed that little tiny UDP requests note in the -h docs too. There's no reason to bind to all tcp addresses, and it is causing me heartburn for getting the server certified... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
rpcbind lingering on IP no longer specified on command line
I had rpcbind running with on two interfaces like this: rpcbind -h 192.168.100.200 -h 10.0.0.9 Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, and I restarted rpcbind. the process list from ps shows it is running like this: rpcbind -h 192.168.100.200 Yet nmap on the other address shows rpcbind is still listening on udp there. How do I stop that? Thanks. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
FWIW, this question could probably have been asked on freebsd-questions@ since it doesn't really pertain specifically to an issue about a stable branch, but that's not the end of the world. Vivek Khera wrote: I had rpcbind running with on two interfaces like this: rpcbind -h 192.168.100.200 -h 10.0.0.9 Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, and I restarted rpcbind. the process list from ps shows it is running like this: rpcbind -h 192.168.100.200 Yet nmap on the other address shows rpcbind is still listening on udp there. How do I stop that? What does 'sockstat | grep rpcbind' tell you? -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Wed, 4 Jan 2006, Doug Barton wrote: DB rpcbind -h 192.168.100.200 -h 10.0.0.9 DB DB Now, I changed rpcbind_flags in /etc/rc.conf to just have the first DB address, and I restarted rpcbind. the process list from ps shows it is DB running like this: DB DB rpcbind -h 192.168.100.200 DB DB Yet nmap on the other address shows rpcbind is still listening on udp DB there. How do I stop that? DB DB What does 'sockstat | grep rpcbind' tell you? Mine (from RELENG_6): [EMAIL PROTECTED]:/usr/src sockstat | grep rpc root rpcbind69422 5 stream /var/run/rpcbind.sock root rpcbind69422 6 dgram - /var/run/logpriv root rpcbind69422 7 udp4 127.0.0.1:111 *:* root rpcbind69422 8 udp4 10.5.5.2:111 *:* root rpcbind69422 9 udp4 *:621 *:* root rpcbind69422 10 tcp4 *:111 *:* [EMAIL PROTECTED]:/usr/src ps ax | grep rpc 69422 ?? Is 0:00.00 rpcbind -h 10.5.5.2 69462 p4 R+ 0:00.00 grep rpc [EMAIL PROTECTED]:/usr/src Hmmm... I just realized that original question mentions udp, not tcp. However, tcp 'listen-to-any' question is still open for me... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Jan 4, 2006, at 2:41 PM, Doug Barton wrote: What does 'sockstat | grep rpcbind' tell you? # sockstat | grep rpcbind root rpcbind11382 5 stream /var/run/rpcbind.sock root rpcbind11382 6 dgram - /var/run/logpriv root rpcbind11382 7 udp4 127.0.0.1:111 *:* root rpcbind11382 8 udp4 192.168.100.200:111 *:* root rpcbind11382 9 udp4 *:664 *:* root rpcbind11382 10 tcp4 *:111 *:* As Dmitry Morozovsky points out, it seems it always listens to tcp *: 111 which seems to be a bad thing. I'm running 6.0-RELEASE-p1. This came up because of some security scans we're having run for some compliance certificates we need... Can anyone explain why rpcbind will still bind to all tcp interfaces? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
