"Tom Lane" <[EMAIL PROTECTED]> 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
