Bug 411761

Summary: rpcbind listens on random, possibly reserved UDP port
Product: [Fedora] Fedora Reporter: Jay Turner <jturner>
Component: rpcbindAssignee: Steve Dickson <steved>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 8CC: lkundrak, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-02 11:02:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 235705    

Description Lubomir Kundrak 2007-12-05 10:21:04 UTC
Description of problem:

I was unable to browse for a remote printer this morning. It turns out that it
was due to fact that cupsd couldn't broadcast the printer as UDP port 631 that
it uses for this purpose was occupied by rpcbind

Version-Release number of selected component (if applicable):

rpcbind-0.1.4-11.fc8

Actual results:

[root@Loori ~]# netstat -lnp |grep 631
tcp        0      0 0.0.0.0:631                 0.0.0.0:*                  
LISTEN      14086/cupsd         
tcp        0      0 :::631                      :::*                       
LISTEN      14086/cupsd         
udp        0      0 0.0.0.0:631                 0.0.0.0:*                      
        1728/rpcbind        
[root@Loori ~]# /etc/init.d/rpcbind stop
Ukončuji rpcbind:                                          [  OK  ]
[root@Loori ~]# /etc/init.d/cups restart
Ukončuji cups:                                             [  OK  ]
Spouštím cups:                                             [  OK  ]
[root@Loori ~]# /etc/init.d/rpcbind start
Spouštím rpcbind:                                          [  OK  ]
[root@Loori ~]# netstat -lnp |grep 631
tcp        0      0 0.0.0.0:631                 0.0.0.0:*                  
LISTEN      14162/cupsd         
tcp        0      0 :::631                      :::*                       
LISTEN      14162/cupsd         
udp        0      0 0.0.0.0:631                 0.0.0.0:*                      
        14162/cupsd         
[root@Loori ~]# netstat -lnp |grep rpcbind
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                  
LISTEN      14778/rpcbind       
udp        0      0 0.0.0.0:961                 0.0.0.0:*                      
        14778/rpcbind       
udp        0      0 0.0.0.0:111                 0.0.0.0:*                      
        14778/rpcbind       
unix  2      [ ACC ]     STREAM     NASLOUCHÁ    80328  14778/rpcbind      
/var/run/rpcbind.sock
[root@Loori ~]#

rpcbind picked another port.

[root@Loori ~]# /etc/init.d/rpcbind restart
Ukončuji rpcbind:                                          [  OK  ]
Spouštím rpcbind:                                          [  OK  ]
[root@Loori ~]# netstat -lnp |grep rpcbind
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                  
LISTEN      14813/rpcbind       
udp        0      0 0.0.0.0:996                 0.0.0.0:*                      
        14813/rpcbind       
udp        0      0 0.0.0.0:111                 0.0.0.0:*                      
        14813/rpcbind       
unix  2      [ ACC ]     STREAM     NASLOUCHÁ    80575  14813/rpcbind      
/var/run/rpcbind.sock
[root@Loori ~]# grep 996 /etc/services 
vsinet          996/tcp                         # vsinet
vsinet          996/udp                         # vsinet
...

After yet another restart it chose another reserved port

Additional info:

How does rpcbind pick ports to listen on? I was told that it looks for unused
ports from /etc/services, which turns out not to be true, and far from being
perfect, as %post scriptlets of anything that would modify /etc/services would
have to condrestart rpcbind.

Does it need a low port for security reasons? Would it be possible to pick a
range of ports it chooses from?

Comment 1 Steve Dickson 2007-12-06 14:11:45 UTC
> How does rpcbind pick ports to listen on?
rpcbind always listens on port 111. 

> Does it need a low port for security reasons?
rpcbind expects applications that register their 
port to use reserved ports but that should be
a short lived connection.

> Would it be possible to pick a range of ports it chooses from?
Unfortunately there is no mechanism that will mask out 
"known" (i.e in /etc/services) reserved ports.




Comment 2 Lubomir Kundrak 2007-12-09 10:21:05 UTC
(In reply to comment #1)
> > How does rpcbind pick ports to listen on?
> rpcbind always listens on port 111. 

When I terminate nfs daemons an ypbind, which I beleve to be the only rpcbind
users and restart rpcbind, there's still a random reserved port in use:

[root@Loori ~]# rpcinfo -s
   program version(s) netid(s)                         service     owner
    100000  2,3,4     local,udp,tcp                    portmapper  superuser
[root@Loori ~]# netstat -lp |grep rpcbind
tcp        0      0 *:sunrpc                    *:*                        
LISTEN      7607/rpcbind        
udp        0      0 *:puparp                    *:*                            
        7607/rpcbind        
udp        0      0 *:sunrpc                    *:*                            
        7607/rpcbind        
unix  2      [ ACC ]     STREAM     NASLOUCHÁ    235733 7607/rpcbind       
/var/run/rpcbind.sock
[root@Loori ~]#

Note the *:puparp.

> > Does it need a low port for security reasons?
> rpcbind expects applications that register their 
> port to use reserved ports but that should be
> a short lived connection.

So if I understand correctly, an application is to blame, though it doesn't look
like that to me from the above. And if it were -- is "short lived" a good excuse
for picking a reserved port?

> > Would it be possible to pick a range of ports it chooses from?
> Unfortunately there is no mechanism that will mask out 
> "known" (i.e in /etc/services) reserved ports.

Would there be any other solution to the problem than writing such mechanism?

Comment 3 Lubomir Kundrak 2007-12-18 20:32:37 UTC
Ping; Any news here?