On Aug 15, 2008, at 15:12, Tom Lane wrote:
The cleanest solution I can think of is to invent some more
pseudotypes
that act just like INTERNAL, and then to require non-privileged CREATE
commands to reference functions that take one of these types instead
of bare INTERNAL. There is a backwards compatibility problem here,
of course, but it wouldn't affect anybody who hadn't written a custom
selectivity estimator, conversion, or analyze function. Which is
probably only the PostGIS project.
+1 # cleanliness++
Failing that, we could just try to keep a registry of possible
signatures for internal-accepting functions, and make sure we don't
accept any patches that cause conflicts. This would avoid creating
backwards compatibility problems, but without any automatic
enforcement
it seems pretty dangerous. (Perhaps a new regression test in the
spirit
of opr_sanity could help, though.)
That won't help pgFoundry modules, though. And since there's been so
much talk about having improved third-party module support, it seems
to me that we ought to try to discourage security holes in such
modules, too.
Another thing that seems like a real good idea is to tighten up
the above-mentioned commands to check for a specific return type and
demand execute permissions. Including the return type in the required
signature is in itself a big improvement in reducing the risk of
accidental matches. This part we could do without creating any
compatibility issues. I also thought about demanding ownership
rather than just execute permission on the functions. That doesn't
seem like it'd fly for selectivity estimators, since it's customary
for user datatypes to re-use the built-in ones, but it might be a
real good idea for conversions.
I did find this strange:
CREATE OR REPLACE FUNCTION citextrecv(internal)
RETURNS citext
AS 'textrecv'
LANGUAGE 'internal' STABLE STRICT;
CREATE OR REPLACE FUNCTION citextsend(citext)
RETURNS bytea
AS 'textsend'
LANGUAGE 'internal' STABLE STRICT;
It'd make a lot more sense to me if bytea was passed to citextrcv,
rather than internal, even if, internally, it used internal (so to
speak). Now you didn't mention CREATE FUNCTION as being one of the
places where this comes up, but it seems to me that it would be
valuable to hide the internal struct, and force SQL users to use only
well-defined types.
Just my $0.02, FWIW.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
