Currently, you're allowed to create a new base type if you own the I/O
functions for it. That effectively restricts the command to superusers
anyway, since there's presently no way for a non-superuser to create
a function that would have the required signature. However that's a
fairly indirect protection against letting a dangerous command be
executed by malicious users; and it would fail given such apparently
innocent-looking changes as allowing PL functions to take or return
cstring. I wonder whether we shouldn't just restrict the command to
superusers explicitly, and thus affirmatively prevent possible future
security holes.
If you're not clear on why CREATE TYPE in the hands of a bad guy is
dangerous, here are a couple of reasons:
* By specifying type representation details (len/byval/align) that are
different from what the type's functions expect, you could trivially
crash the backend, and less trivially use a pass-by-reference I/O
function to read out the contents of backend memory.
* The just-added ability to specify a new type's type category and
"preferred" status could allow subverting the behavior of existing
queries that expect ambiguous operators to be resolved in a particular
way. A new preferred type could "capture" such queries and thereby
provide a trojan-horse vector for executing functions as some other
user.
There might be some other attacks I've not thought of.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
