RH Taroon Beta Open Ports
hbo at egbok.com
Mon Aug 25 21:35:03 UTC 2003
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
> > don't
> > 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
> hell ;-)
> Just my two cents of Euro.
> Rhl-devel-list mailing list
> Rhl-devel-list at redhat.com
Howard Owen "Even if you are on the right
EGBOK Consultants track, you'll get run over if you
hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers
More information about the devel