"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> 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.
I know when I was first starting out it was a big source of frustration that
you have to get those arguments right.. Until I figured out what they all
meant and how to use them I was constantly crashing the server.
It seems to me we should be able to do better. To have some kind of struct in
the C code associated with the input/output functions from which the create
type command picks up these parameters.
As a consequence we could perhaps aim to make creating new types safe rather
than just deal with the fact that it's not safe currently? It would be nice if
non-superusers could create types which used an existing set of input/output
functions but defined new semantics.
> * 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.
Would it be enough to only require super-user to create a preferred type?
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!
