From owner-freebsd-net  Thu Feb  8 10:31:59 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id C73B137B6AA
	for <net@freebsd.org>; Thu,  8 Feb 2001 10:31:40 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id f18IWd120580;
	Thu, 8 Feb 2001 12:32:39 -0600 (CST)
	(envelope-from jlemon)
Date: Thu, 8 Feb 2001 12:32:39 -0600
From: Jonathan Lemon <jlemon@flugsvamp.com>
To: Archie Cobbs <archie@dellroad.org>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@freebsd.org
Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake]
Message-ID: <20010208123239.P650@prism.flugsvamp.com>
References: <200102081701.f18H1Vp17229@prism.flugsvamp.com> <200102081812.KAA56568@curve.dellroad.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <200102081812.KAA56568@curve.dellroad.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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 majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message