127.0.0.1 is just another interface. All possible errors can happen.
Imagine a server where the load is high enough that other processes don't
get to run much... they write to localhost, expecting what's on the other
end to get it, but the localhost interface buffers overflow.
Or the misconfigured routed that brings down the route to 127.0.0.1, or
routes it to Timbuktu.
Or the novice sysadmin who decides to ifconfig [lo|l0|lo0] down.
(Yes, I've seen all of these situations happen. The second one, I can't
remember why we figured that the UNIX didn't read it anyway, since it had
an interface with the destination IP number, but it routed it before
checking its local interface list.)
Assertions only belong in debugging code, not production code. In
production code, reliability/robustness is more important than 'proper
coding'. Granted, gcache is fixed now, but in the event of an error, if
I'd coded it, I would have logged the error and moved on -- not died the
first time an I/O operation failed to return the expected number of bytes.
('robust' means 'fault-tolerant', among other things.)
My $0.02, if it's worth anything. But if that's the way you code
Apache-SSL, I'm very glad my friend pointed me to mod_ssl.
-Mat Butler
---
Mat Butler, Winged Wolf <[EMAIL PROTECTED]>
SPASTIC Web Engineer SPASTIC Server Administrator
----Begin FurryCode v1.3----
FCWw5amrsw A- C+ D H+++ M+++++[servercoder] P+ R++ T+++ W Z++ Sm++
RLCT/M*/LW* a cl/u/v++++>+++++ !d e- f>++++ h++ iwf+++ j p->+ sm++
----End FurryCode v1.3----
On Sat, 31 Oct 1998, Ben Laurie wrote:
> Ralf S. Engelschall wrote:
> >
> > On Sat, Oct 31, 1998, Ben Laurie wrote:
> >
> > > Ralf S. Engelschall wrote:
> > > > Hmmmm??? Do you mean it cannot occur in practice? Or do I misunderstand you
> > > > here. As I said: We not even need an attacker: When an I/O read error occurs
> > > > for gcache it already falls down. So the DoS attacker is just the worst case.
> > >
> > > Aha. Now we get down to it. OK, please describe how an I/O error can
> > > occur on a locally connected socket.
> >
> > How it actually can occur I don't know. Depends on the platform, I think. But
> > in general I don't think that Unix guarantees that a TCP connection to
> > localhost always can be performed without any problems. I've no actual
> > scenario of an I/O communication error at hand, but I've at least the code
> > parts at hand which then could fail:
> >
> > | nRead=saferead(nFD,&usLength,sizeof usLength);
> > | assert(nRead == sizeof usLength);
> >
> > Here the assert makes sure that really the requested number of bytes are read.
> > But when an I/O error or some other communication problem occurs the actual
> > number of read bytes can be different. Then the gcache process falls down.
> > And I've seen exactly gcache exits with this assertion on my boxes (Solaris
> > 2.6) while I was mostly sure that no personal attacker was involved. Instead
> > I really assume it was just some I/O communication error...
>
> This is exactly where it failed when gcache was crashing because of a
> bug. Could it be that you assumed there was a network error instead?
> Since gcache was fixed I have had no reports of this assertion failing.
>
> I do not believe that an I/O error is possible on a locally connected
> socket. I would be most reluctant to fix this without evidence that it
> is actually a bug. Since this seems to be the thread for maxims, one of
> my favourites is "if you don't understand why it is broken, don't fix
> it", and I intend to stick to that.
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
> and Technical Director|Email: [EMAIL PROTECTED] |
> A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
> ______________________________________________________________________
> Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
> Official Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
