sshd fails to close open file descriptors when forking

[Ed Phillips]

On Sat, 20 Oct 2001, Lutz Jaenicke wrote:

> Date: Sat, 20 Oct 2001 08:15:33 +0200
> From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: sshd fails to close open file descriptors when forking
>
> 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.

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...)

	Ed

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