| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Justin Clift" <justin(at)postgresql(dot)org> |
| Cc: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Vince Vielhaber" <vev(at)michvhf(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
| Date: | 2002-08-20 16:36:58 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961E50@m0114.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-08-20 16:40:52 | Re: Build failure in current CVS (src/backend/utils/mb/conversion_procs) |
| Previous Message | Florian Weimer | 2002-08-20 16:31:28 | Re: [SECURITY] DoS attack on backend possible |