sshd fails to close open file descriptors when forking

Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE
Sat Oct 20 16:15:33 EST 2001


On Fri, Oct 19, 2001 at 06:11:40PM -0400, James Ralston wrote:
> On Fri, 19 Oct 2001, Ed Phillips wrote:
> > On Thu, 18 Oct 2001, James Ralston wrote:
> >
> > > Date: Thu, 18 Oct 2001 16:45:13 -0400 (EDT)
> > > From: James Ralston <qralston+ml.openssh-unix-dev at andrew.cmu.edu>
> > > To: openssh-unix-dev at mindrot.org
> > > Subject: sshd fails to close open file descriptors when forking
> > >
> > > I don't like to be the bearer of bad news, but...
> > >
> > > In light of the big "ssh hangs on logout" thread (wherein the true
> > > culprit was identified as being programs that don't close inherited
> > > file descriptors), I find it somewhat ironic that one of those "broken
> > > daemon" programs that doesn't close its open fds is sshd.  :(
> > >
> > > http://bugzilla.mindrot.org/show_bug.cgi?id=3
> > >
> > > (At least it shouldn't be too difficult to fix...)
> >
> > So how exactly does sshd exit without closing it's (inherited or
> > other) file descriptors?  ;-)
> 
> I don't understand your question.  Could you rephrase?

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.

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153



More information about the openssh-unix-dev mailing list