sshd fails to close open file descriptors when forking

Ed Phillips ed at UDel.Edu
Tue Oct 23 01:03:26 EST 2001

On Mon, 22 Oct 2001, Lutz Jaenicke wrote:

> Date: Mon, 22 Oct 2001 15:46:22 +0200
> From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> To: openssh-unix-dev at
> Subject: Re: sshd fails to close open file descriptors when forking
> On Mon, Oct 22, 2001 at 09:36:19AM -0400, Ed Phillips wrote:
> > On Sat, 20 Oct 2001, Lutz Jaenicke wrote:
> > > The point is: how do you come to your conclusion?
> > > daemon() calls dup2() for the file descriptors 0, 1, 2 (stdin, stdout, stderr)
> > > and newly assigns them /dev/null. My manual page (HP-UX) says:
> > >       dup2() causes fildes2 to refer to the same file as fildes.  If fildes2
> > >       refers to an already open file, the open file is closed first.
> > > Consequently the open files at 0, 1, 2 are closed.
> > > So without further explanation or evidence I consider your bug report
> > > to be wrong.
> >
> > Actually, my point was, when sshd exits (calls exit() or whatever), no
> > matter what file descriptors are open, they'll all get closed as the
> > actual process exits.  (But even so, ssh on the other end still hangs...
> > potentially depending on which version of ssh you're running...)
> I still don't get your point. When sshd exits, all of its file descriptors
> are being closed (meaning: they are closed with respect to the exiting
> process). If a process has forked and the forked process has the
> same file descriptors open, they are still open from the system's point
> of view. So what?

But the child processes don't have the _same_ file descriptors open, do
they?  I thought they had a pipe(s) back to the sshd for protocol
encoding/decoding.  Regardless, all the children need to exit _before_
sshd exits, and when they do, all of the file descriptors will be closed.
When sshd exits, there should be no open file descriptors, right?  (And if
sshd exits when there is a process that has a file descriptor open that is
a "connection" back to the ssh client, then that's a bug, right?) Am I
missing some key point here?  It seems simple... ;-)


Ed Phillips <ed at> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed at for PGP public key

More information about the openssh-unix-dev mailing list