Re: Output functions with multiple arguments considered harmful

On Sat, Apr 30, 2005 at 04:17:59PM -0400, Tom Lane wrote:
> An example that Elein put up yesterday:
> http://archives.postgresql.org/pgsql-general/2005-04/msg01384.php
> caused me to realize that type output functions that depend on
> additional arguments to determine what they are dealing with are
> fundamentally security holes.  It is trivial to crash 8.0's record_out
> by lying to it about the rowtype of its first argument.

Is it not as trivial to crash it if one passes bad data into it?
Why is the oid arg worse than the data arg?  Could it be possible
that those built-in generic type output functions that take OIDS
should check more carefully.  I believe this is an issue primarily
wrt generic types.

> 
> I have fixed that in CVS tip (and I suppose we had better think about
> a security update) ... but what I am now contemplating is taking steps
> of various levels of draconianness to make sure we don't get burnt this
> way again.  At a minimum I am going to change the type_sanity regression
> test to complain about built-in output functions that have multiple
> arguments.  I am also fairly strongly tempted to modify CREATE TYPE so
> that it doesn't allow user-defined types to have multi-argument output
> functions, either.  I doubt there is anyone out there trying to do that,
> because the extra arguments that are passed don't seem useful for any
> non-builtin types.  But I thought I should throw it out for discussion
> --- has anyone got a problem with such a change?

I think a distinction needs to be made with super types.  The generic types
are super types at this time. But remember the grand-parental issue just recently
discussed? http://archives.postgresql.org/pgsql-hackers/2005-04/msg00402.php
Theoretically any time can be a super type which does complicate things.

I believe the generic types' output functions need to be able to be told
what sort of thingy they are expecting to be.  Maybe we can bury this to
internal functions only by enabling casting of unnamed row types, generic arrays,
and other super types in SQL.  Which was my original issue. 

I'm not at a place to retest but shouldn't i be able to do 
myrowtype( ) around anything to cast it to a "myrowtype", successfully or not?

> 
> BTW, the comparable arguments for input functions are not dangerous, and
> in fact are necessary.  The reason they are not dangerous is that every
> datatype input converter applies sufficient sanity checks to input text
> strings to not accept invalid input.  We have an issue on the output
> side because internal representations are generally taken on faith to be
> valid (and would be hard to validate even if we tried).

> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
> 

Elein
elein@varlena.com