Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

"Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> writes:
>> I'd like to see something done about this fairly soon, but it's not
>> happening for 7.3 ...

> Does anyone have an idea about what other functions are affected by this?

As a first approximation, every output function for a built-in
pass-by-reference datatype will show this same behavior. cash_out is
just getting picked on because it was the one mentioned in the first
complaint. For that matter, every input function for any datatype
has the same problem:
regression=# select cash_in(2);
server closed the connection unexpectedly

Let's see ... I count 264 standard pg_proc entries that are declared
with one or more "opaque" parameters. Many but by no means all are I/O
functions. There are another 13 standard functions declared to return
"opaque". To plug the hole in a credible fashion we'd need to do
something about every one of these; so belay that last suggestion that
just implementing a "C string" pseudo-type would be enough to be
meaningful.

Right offhand it looks like we'd need at least:
"C string" for the I/O functions
"internal type" for index access functions, selectivity, etc
"any array" for array_eq and array_dims
"any type" for count(*) (and not much else!)
"tuple" for the return type of trigger functions
"void" for the return type of things that return void
not sure about encoding conversion functions

The functions handling internal-type stuff are probably things we don't
want the user calling at all. As long as we don't declare any of them
to *return* an internal type, there would be no way to construct a
function call that the parser would accept, so that hole would be
plugged with just one pseudo-type; we don't really need to distinguish
which internal type is meant in any one case. The "any array"
pseudo-type would probably take a special-case kluge in parse_coerce,
but that doesn't seem intolerable.

Anyone see something I missed? Tatsuo, what exactly should the function
signature really be for all those encoding conversion functions you just
added?

regards, tom lane