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