Bug 456401

Summary: [RFE] prevent RPC services from grabbing port of other known services
Product: [Fedora] Fedora Reporter: Kamil Dudka <kdudka>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: drepper, fweimer, ovasik, rc040203
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-07-26 07:33:15 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:
Attachments:
Description Flags
proposed patch for glibc/sunrpc none

Description Kamil Dudka 2008-07-23 11:31:26 UTC 
Description of problem:
RPC services grab port of other known services on boot. Known bugs:
#223937 - rpc.rquotad grabs port 993 breaking dovecot IMAPs
#103401 - RPC port selection for ypbind may collide with CUPS port on boot
and at least 12 other closed as duplicates to these bugs

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

How reproducible:
always

Steps to Reproduce:
1. let commented line RQUOTAD_PORT=875 in /etc/sysconfig/nfs (default)
2. add no entry for rquotad to /etc/services (default)
3. start rpc.rquotad as root
  
Actual results:
rpc.rquotad grabs an random port in range 600-1023

Expected results:
rpc.rquotad (and other RPC services) should never grab port of other known 
service

Additional info:
As solution to these bugs I propose a patch in attachment. This patch prevent 
RPC services to grab port of other known services. It does not change the 
interface in any way. So all affected RPC services will start working while 
using glibc with this patch.
Comment 1 Kamil Dudka 2008-07-23 11:31:26 UTC 
Created attachment 312464 [details]
proposed patch for glibc/sunrpc
Comment 2 Ulrich Drepper 2008-07-26 07:33:15 UTC 
Nonsense.  Almost all ports are assigned.  The way to assure ports are not
assigned otherwise is explicitly allocate them.  See Tim Waugh's

http://cyberelk.net/tim/software/portreserve/
Comment 3 Kamil Dudka 2008-07-28 07:32:14 UTC 
We have only 190 ports assigned (rawhide setup) in range 600-1023. So it is 
about 45%. I don't think 45% is "almost all".
Comment 4 Michal Hlavinka 2012-11-08 14:12:53 UTC 
*** Bug 873188 has been marked as a duplicate of this bug. ***