Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E50@m0114.s-mxs.net
Whole thread Raw
Responses Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> The cash_out problem can't really be fixed until we do something about
> subdividing type "opaque" into multiple pseudo-types with more carefully
> defined meanings.  cash_out is declared cash_out(opaque) which does not
> really mean that it accepts any input type ... but one of the several
> meanings of "opaque" is "accepts any type", so the parser
> doesn't reject cash_out(2).

Would it be possible to update the system tables, so that cash_out does not take
opaque but really takes type money ?
I mean the first thing cash_out does is PG_GETARG_CASH(0), so it really only copes
with a money type.

I know the problem is that the cat chases its tail here, because of what comes first,
the type or the io functions. But couldn't this be overcome, at least for internal types ?

Andreas


pgsql-hackers by date:

Previous
From: Florian Weimer
Date:
Subject: Re: [SECURITY] DoS attack on backend possible
Next
From: Tom Lane
Date:
Subject: Re: Build failure in current CVS (src/backend/utils/mb/conversion_procs)