Re: libpq++ tracing considered harmful (was Re: libpq++ memory problems)

Tom Lane wrote:
> Ah-hah, figured it out.  There *was* a recent relevant change, but the
> log message for it didn't say anything about leaks.  The problem is
> in the "debug" code for PgConnection, which in 6.5.* looks like:

[snip]

> 1. "DEBUG" is a symbol defined in the backend header files (it's a
>    severity level constant for elog()).  So although libpq++'s Makefile
>    thinks it can turn the code on or off via -DDEBUG, it's mistaken;
>    that debug-tracing code always gets compiled.
>    Oliver Elphick fixed that a month or so ago by changing the
>    controlling symbol to "DEBUGFILE".  So that's why you see the leak
>    in 6.5.3 and I don't see it in current sources.
> 4. If any tracing did occur, all of the output from (perhaps many)
>    different PgConnection objects in different program runs would all
>    get dumped into the same temp file, leaving it of doubtful use to
>    anybody.
> 5. One could reasonably doubt that it's a good idea to have a compiled-in
>    option to dump the entire trace of a program's interaction with the
>    backend into a publicly readable temp file.  Can you say "security
>    hole"?  Seems to me that this function should require a specific

Hmmmm..  

>    request from the application, not be something that could accidentally
>    get installed as the default behavior of a system library.  (Think
>    what would happen if RPMs containing such behavior got distributed...)

Yes, think of it.  How many other such 'surprises' lurk, I wonder?
> Perhaps something can be salvaged from the wreckage, but for now the
> right answer is just to make sure that this code is not compiled.

And to compile this code you supply _which_ configure option?  Which is
the default (which is how the RPMset is built)?  Or is this like one of
the many options in config.h.in (or config.h, depending on which side of
the configure divide you prefer to edit....), like so many other options
that aren't configure'able?

This is as good an argument as any for a single, canonical, RPMset as
I've seen in a while, Tom.  I (and others in the development group who
can help watchdog the RPMset) just have to be extra-diligent to make
sure stuff like compiling this freakish code doesn't happen.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11