Steve Dickson wrote:
>> statd (i.e. nfslock) probably does not need to be running if NFS is
>> not configured but
>> tunning off portmapper is a bit extreme... Not only do local process
>> expect portmapper
>> to be there,
> Which local processes? We've already heard about sgi_fam, and we already
> know about NIS and NFS, but is this really worth leaving it listening on
> external interfaces in a _default_ install?
third party applications of our beloved customers... There are
*probably* a few more
applications other than NFS and NIS that need to advertise ports....
RPC subsystem has been around for a very long time which means we
what we would be breaking by turning it off... Just because you don't
something..... does not mean they don't exist....
Your missing the point here. No one is saying don't ship portmap or nfs
utilities. Just raising the question as to whether they should be
enabled by default.
>> point being turning off portmapper could (and probably will) cause
>> unexpect process
>> to fail in unexpect ways making very difficult to debug especially
>> during installation...
> As a matter of course, I disable portmap and rpc.statd on any machine
> expected to perform NFS or NIS and have not noticed any side effects
> as a
So we can assume that your system is an *exact* clone of every other
out there... so what works in your world will work everywhere.... I'm
I just don't by your logic...
I also disable them on my systems since I don't typically utilize NFS
(nor NIS, or any other RPC based service) and I have not had any
problems either. Using the recent MS DCOM problems, MS' technical
information for the problem suggested a workaround of disabling DCOM
with the following nebulous disclaimer:
*Warning* If you disable DCOM, may you may lose operating system
functionality. After you disable support for DCOM, the following may
* Any COM objects that can be activated remotely may not function
* The local COM+ snap-in will not be able to connect to remote
servers to enumerate their COM+ catalog.
* Certificate auto-enrollment may not function correctly.
* Windows Management Instrumentation (WMI) queries against remote
servers may not function correctly.
It translates to most folks as "If I disable DCOM, no one knows what is
going to break". With a stock RH install, how many RPC using services
are available? NFS, NIS, sgi_fam, and?? Unlike MS, you know what will
not function if portmap is not running. 3rd party apps are certainly a
different ballgame, but that is the 3rd parties responsibility to
mention the requirement of portmap.
>> Portmapper has been around quite a long time making it pretty bullet
> Funny, 'cos in my universe, the portmapper is regarded as one of the
> vulnerable pieces of UNIX software, along with rpc.statd, sendmail
> and BIND.
Educate me... How has it *recently* (i.e within the that 3 years)
And what damage was caused?
>> So I see no reason what so ever to turn off portmapper. Lets not make a
>> system more difficult to deal with for simply no reason...
> ...but there is a reason - making new installs secure by default. For a
> admin who's already configuring NFS or similar, the extra step of
> chkconfig'ing portmap and rpc.statd isn't much of a burden.
Again.... NFS and NIS are not the only user of portmapper... We have
in mind the entire industry... not just or own little worlds....
Rhl-devel-list mailing list