Bug 458448 - ypbind opens a second UDP port which doesn't use the number passed to -p
ypbind opens a second UDP port which doesn't use the number passed to -p
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ypbind (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Klíč
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 505380
  Show dependency treegraph
 
Reported: 2008-08-08 10:13 EDT by Michael Ploujnikov
Modified: 2013-03-03 17:59 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 06:42:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Ploujnikov 2008-08-08 10:13:31 EDT
Description of problem:
In an attempt to use ypbind on a firewalled NIS client I tried forcing ypbind to listen on a pre-defined port so that I would know how to configure my firewall to exclusively allow incoming traffic on that port. According to the ypbind manual I'm supposed to use the -p option to tell ypbind which port number to use. I tried passing the '-p 833' option and ypbind seemed to use that number for a TCP port and a UDP port. However, it also opened a second UDP port which seemed to be randomly selected each time I ran ypbind. Unfortunately, I couldn't get my firewall to know which port to unlock and this completely prevented ypbind to bind to my organization's NIS server.


Version-Release number of selected component (if applicable):
ypbind.i386                              3:1.20.4-6.fc9

How reproducible:
Always

Steps to Reproduce:
1. ypbind -p 833
2. netstat -natup|grep ypbind
3. pkill ypbind
4. ypbind -p 833
5. netstat -natup|grep ypbind
  
Actual results:
tcp        0      0 0.0.0.0:833                 0.0.0.0:*                   LISTEN      21650/ypbind        
udp        0      0 0.0.0.0:833                 0.0.0.0:*                               21650/ypbind        
udp        0      0 0.0.0.0:634                 0.0.0.0:*                               21650/ypbind        

tcp        0      0 0.0.0.0:833                 0.0.0.0:*                   LISTEN      21663/ypbind        
udp        0      0 0.0.0.0:647                 0.0.0.0:*                               21663/ypbind        
udp        0      0 0.0.0.0:833                 0.0.0.0:*                               21663/ypbind


Expected results:
I was expecting to see only one UDP port and such that its number what I requested with -p.

Additional info:
Having two UDP ports might be a design choice, but unless I can control which numbers they are set to, ypbind really can't be used on NIS clients with a firewall enabled. I guess the easiest solution would be to allow users to select the second UDP port's number too.
Comment 1 Thomas Moschny 2008-08-08 10:37:13 EDT
If you issue the netstat command from time to time for a longer period, you'll see that the 'third' udp port changes over time.

I *think* this is used as originating port for pinging servers, so I'm not sure how relevant its number is for configuring the firewall.
Comment 2 Michael Ploujnikov 2008-08-08 11:11:39 EDT
I haven't noticed that it changes, and it's depressing to know that it does. I verified that ypbind is able to bind to the NIS server only when I open ports 833 _and_ that random port. Whatever that port is used for, it totally makes NIS unusable if a firewall is turned on. I wish I could find some documentation about this port. If you really want, I could show the relevant firewall config and ypbind output.
Comment 3 Michael Ploujnikov 2008-08-12 09:45:27 EDT
# #netconfsoapbeep is the same as port 833
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:netconfsoapbeep 
ACCEPT     udp  --  anywhere             anywhere            state NEW udp dpt:netconfsoapbeep 
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
# ypbind -debug -p 833
4806: parsing config file
4806: Trying entry: domain my.domain.com broadcast
4806: parsed domain 'my.domain.com' broadcast
4806: add_server() domain: my.domain.com, broadcast
4806: [Welcome to ypbind-mt, version 1.20.4]

4806: ping interval is 20 seconds

4808: NetworkManager is not running.

4809: do_broadcast() for domain 'my.domain.com' is called
4809: broadcast: RPC: Timed out.
4809: leave do_broadcast() for domain 'my.domain.com'
^C4807: Signal (2) for quitting program arrived.

# # while do_broadcast() was running I saw this:
# netstat -natup|grep ypbind
tcp        0      0 0.0.0.0:833                 0.0.0.0:*                   LISTEN      4806/ypbind         
udp        0      0 0.0.0.0:43540               0.0.0.0:*                               4806/ypbind         
udp        0      0 0.0.0.0:833                 0.0.0.0:*                               4806/ypbind         

# after leave do_broadcast() happened I saw this:
[root@dynamic-25 ~]# netstat -natup|grep ypbind
tcp        0      0 0.0.0.0:833                 0.0.0.0:*                   LISTEN      4806/ypbind         
udp        0      0 0.0.0.0:833                 0.0.0.0:*                               4806/ypbind

All of means that I wasn't able to connect to my NIS server while the firewall was turned on.
Comment 4 Michael Ploujnikov 2008-08-12 09:51:52 EDT
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
# ypbind -debug -p 833
5084: parsing config file
5084: Trying entry: domain my.domain.com broadcast
5084: parsed domain 'my.domain.com' broadcast
5084: add_server() domain: my.domain.com, broadcast
5084: [Welcome to ypbind-mt, version 1.20.4]

5084: ping interval is 20 seconds

5086: NetworkManager is not running.

5087: do_broadcast() for domain 'my.domain.com' is called
5087: Answer for domain 'my.domain.com' from server 'keyserver.my.domain.com'
5087: leave do_broadcast() for domain 'my.domain.com'

# # in a different terminal, right after leave do_broadcast():
# netstat -natup|grep ypbind
tcp        0      0 0.0.0.0:833                 0.0.0.0:*                   LISTEN      5084/ypbind         
udp        0      0 0.0.0.0:833                 0.0.0.0:*                               5084/ypbind         
udp        0      0 0.0.0.0:604                 0.0.0.0:*                               5084/ypbind  
# # and a minute later:
# netstat -natup|grep ypbind
tcp        0      0 0.0.0.0:833                 0.0.0.0:*                   LISTEN      5084/ypbind         
udp        0      0 0.0.0.0:833                 0.0.0.0:*                               5084/ypbind         
udp        0      0 0.0.0.0:606                 0.0.0.0:*                               5084/ypbind  

This shows that ypbind is able to connect to my NIS server if the firewall is completely turned off. It also confirms that the random UDP port number is changing over time.
Comment 5 Michael Ploujnikov 2008-08-12 09:56:05 EDT
In my trials I noticed that ypbind is able to get an "Answer for domain" if it accidentally starts listening on an open UDP port, but this is obviously not an acceptable solution because the timeout delays are long and the chances of hitting an open port are low. While ypbind is waiting for an answer the client machine becomes severely limited in functionality because things UID lookups don't return for prolonged periods of time. As a specific example, I have to wait for ypbind to work before a new terminal emulator can open.
Comment 6 Vitezslav Crhonek 2008-12-05 07:27:20 EST
(In reply to comment #1)
> I *think* this is used as originating port for pinging servers, so I'm not sure
> how relevant its number is for configuring the firewall.

That's true. The second port is used for pinging servers and which port is used is  up to RPC manager (called rpcbind now, portmap before). -p port option is useful only when you need access ypbind service from hosts on the network.
Comment 7 Bug Zapper 2009-06-09 22:24:18 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Michael Ploujnikov 2009-06-16 14:30:35 EDT
This is still a problem in ypbind-1.20.4-19.fc11.i586.
Comment 9 Bug Zapper 2010-04-27 08:11:12 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2010-06-28 06:42:35 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.