I agree with this.
While it wouldn't help with third party apps, the init scripts for
nfs and ypserv could (briefly) explain the changed behavior
wrt the portmapper. In this way the admin could be pointed to
documentation that would explain how to turn on the service, together
with why you really shouldn't. 8)
As Linux gets more and more market penetration, particularly on the
desktop, we will start to suffer from many of the syndromes that
Microsoft is so poor at coping with. I'm confident we will do better
when dealing with increased visibility and less clueful users and
admins. That's because of an inherently better platform, and because
people will have thought longer, better and with more experience backing
them about the challenges widespread success will raise.
On Mon, 2003-08-25 at 12:36, Felipe Alfaro Solana wrote:
On Mon, 2003-08-25 at 20:18, Steve Dickson wrote:
> >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....
> Remember the
> RPC subsystem has been around for a very long time which means we really
> what we would be breaking by turning it off... Just because you don't
> know about
> something..... does not mean they don't exist....
In my humble opinion, sometimes we must take decisions that make
difficult mantaining compatibility. However, if these decisions are
targeted to achieve improved security, I think we have a reason in our
favor. NFS is not very secure by nature (except NFSv4).
If we want to mantain compatiblity with third-party products, I suggest
that during upgrades, the portmap and company be left at their original
settings. However, for new installations, I think we should disable
them, or at least, force them to bind to the loopback interface
exclusively. Then, I would put a *big* note into the Release Notes
stating behavior changes in those services.
Red Hat (or anyone) can't be liable for a behavior change that is well
documented in the Release Notes and aims at security: if an
administrator performs a fresh install of Red Hat Linux, then installs
third-party products and checks that some things don't work, then, if
he/she hasn't read the Release Notes, he/she should be sent to the IT
Just my two cents of Euro.
Rhl-devel-list mailing list
Howard Owen "Even if you are on the right
EGBOK Consultants track, you'll get run over if you
hbo(a)egbok.com +1-650-339-5733 just sit there." - Will Rogers