Skip site navigation (1) Skip section navigation (2)

Output functions with multiple arguments considered harmful

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Output functions with multiple arguments considered harmful
Date: 2005-04-30 20:17:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
An example that Elein put up yesterday:
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

Next:From: Tom LaneDate: 2005-04-30 21:12:39
Subject: pg_locks needs a facelift
Previous:From: Robert TreatDate: 2005-04-30 19:14:28
Subject: Re: [HACKERS] Increased company involvement

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group