Output functions with multiple arguments considered harmful - Mailing list pgsql-hackers

From Tom Lane
Subject Output functions with multiple arguments considered harmful
Date
Msg-id 17076.1114892279@sss.pgh.pa.us
Whole thread Raw
Responses Re: Output functions with multiple arguments considered harmful  (elein@varlena.com (elein))
Re: Output functions with multiple arguments considered  (James William Pye <pgsql@jwp.name>)
List pgsql-hackers
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.

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?

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


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement
Next
From: Tom Lane
Date:
Subject: pg_locks needs a facelift