Alleged bug in resolver code

[Mark Kettenis]

   Date: Fri, 14 Jul 2000 15:56:02 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Sat, Jul 15, 2000 at 12:46:45AM +0200, Mark Kettenis wrote:
   > I'm willing to believe that you actualy saw if bug, but the suggested
   > fix (initializing _res._sock to -1, and doing the same for the
   > per-thread resolver state) that was checked in cannot be the right
   > solution.  You see, calling res_close() without first sucessfully
   > having called res_init(), or calling res_nclose(statp) without
   > res_ninit(statp) is simply a programming mistake, and will obviously
   > invoke undefined behaviour (such as close(0)).  This behaviour isn't
   > any different than what the resolver in glibc 2.1 did.  As such, what
   > you describe here obviously isn't a bug.

   I have no idea what your glibc 2.1 looks like. Mine has

   static int s = -1;      /* socket used for communications */
   static int connected = 0;       /* is the socket connected */
   static int vc = 0;      /* is the socket a virtual circuit? */

Oops.  Looks like I looked in the wrong places.

   It is 100% ok to call res_close () without calling res_init () first
   in my glibc 2.1.

The fact that it simply works in glibc 2.1 doesn't mean it's right.

1. res_close() is undocumented, it's not in the glibc manual, not
   on the Linux resolver(3) man page, not on the BIND-4.9.7-REL
   resolver(3) not on any of the BSD resolver(3) man pages.  Heck it's
   not even exported by the Solaris /usr/lib/libresolv.so.2 library.

2. res_close() is clearly marked with:

   /*
    * This routine is for closing the socket if a virtual circuit is used and
    * the program wants to close it.  This provides support for endhostent()
    * which expects to close the socket.
    *
    * This routine is not expected to be user visible.
    */

   Unfortunately this has become a bit less clear in glibc 2.1 because
   of renaming the origional function to res_close_internal().

3. Calling res_close() before res_init() makes absolutely no sense.

   > 
   > Now there is actually a problem with res_init() in multi-threaded
   > programs that might have caused the problems you were seeing.
   > Unfortunately your report didn't provide a test-case either.  Could
   > you privide one?  If so I'm willing to do some additional testing,
   > before sending my updated BIND code to Ulrich.
   > 

   The program I was having trouble with is pump from Red Hat.

Thanks for the info!

[After having a struggle with RPM]

Looks like a piece of shoddy software to me.  I don't think its
existence is enough reason for us to put another 512+ bytes in the
data segment.  A better fix would be to check if RES_INIT is set in
_res.options and bail out if it isn't in res_close().  But IMHO pump
should be fixed.  Unfortunately for Red Hat they make it too hard for
me to file a bug report, so they loose.

Mark