Bug 219026 - Portmap and rpc.statd started by default
Portmap and rpc.statd started by default
Product: Fedora
Classification: Fedora
Component: portmap (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Depends On:
  Show dependency treegraph
Reported: 2006-12-09 10:18 EST by Steve Hill
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-12-14 09:07:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Hill 2006-12-09 10:18:05 EST
Description of problem:
Both portmap and rpc.statd are started by default and listen to the network for
connections.  Starting unnecessary network services by default doesn't seem to
fit with the "secure by default" methodology.

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

How reproducible:

Steps to Reproduce:
1. Install FC6
Actual results:
Portmap and rpc.statd running and listening for network connections after boot.

Expected results:
Network services should only be started after the user enables them (either
explicitly or by a dependent service being enabled).

Additional info:
Comment 1 Steve Dickson 2006-12-11 13:41:36 EST
These are needed by the NFS client  to mount remote filesystem... and 
I really don't thing we want the kernel or mount command start them... 
So I would like to close this as NOTABUG... 

Comment 2 Steve Hill 2006-12-12 04:38:50 EST
The /etc/rc.d/init.d/netfs init script appears to automagically start portmap if
necessary anyway.  (Although clearly this only helps if you're using the netfs
init script to mount your remote file systems).
Comment 3 Steve Dickson 2006-12-14 08:01:29 EST
Well, you can also mount NFS filesystem by hand... and if
portmapper and nfslock was not running, those would
Comment 4 Steve Hill 2006-12-14 09:07:50 EST

Ok, I'm happy to accept this is not really - closing the bug.

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