On Thu, Feb 08, 2001 at 10:12:43AM -0800, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > >> Jayanth did make one point that an application could assume that
> > >> the error return from accept was in regards to the listening socket
> > >> instead of the new socket, so that may be a concern.
> > >
> > >Yes I have always assumed this to be true. If the connection is
> > >already broken before I get it, why bother giving it to me??
> >
> > Because the connection may be broken between the point where we've
> > notified the user that there is a valid connection, and when accept
> > returns. E.g.:
>
> It was a rhetorical question. I like Robert's suggestion to return
> the socket but have the first operation on the socket fail.
>
> If you want to positively verify the new socket you can do a
> getpeername(), etc.
>
> > I would guess that code is more likely to check for an error
> > return from accept() than it is to check the return size from
> > the sockaddr, so this change will proabably not result in breaking
> > a large amount of code.
>
> IMHO the app is more likely to close the listen socket and stop
> accepting new connections if it gets an error from accept().
>
> For example, from an initial scan of sendmail (daemon.c:403) if
> it gets an error from accept(2) it will close the (listen) socket
> and reopen it. Sendmail is robust enough not to "break" but this
> shows that if it gets an accept(2) error it assumes the problem is
> with the *listening* socket, not the new socket.
Yes, I looked at sendmail, ftpd, sshd, telnetd, inetd, and apache.
Only apache does the right thing in this case. All the other
applications either:
1. handle the error from accept() in some form (which may
include terminating the application), or
2. blindly use the returned sockname.
So in sendmail's case, it currently does:
t = accept(.., (struct sockaddr *)&RealHostAddr, &lotherend);
....
p = hostnamebyanyaddr(&RealHostAddr);
which will proabably coredump since it dereferences a NULL pointer.
I'd think that at least having sendmail close/reopen the listen socket
will result in slightly more robust behavior.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
