I wrote:
> For the range-type support functions, it would be simple enough to check
> call permission at range-type definition time.  But I really don't want
> to put in a run-time check, because there doesn't seem to be a very
> practical way to do it less often than every call, and besides that it's
> not very clear who to blame an index operation on.  Is it good enough to
> test this only at range-type creation time?  The implication of course is
> that you might not be able to revoke execute permission from a bad guy,
> short of dropping your function.  This might be all right given the
> relatively narrow cross-section of functions that could be called this
> way.

On further reflection I think we can get away with this, because of the
additional check that's already in there that insists the support
functions be IMMUTABLE.  That means they can't have any side-effects,
which makes the potential security consequences of unauthorized calls
very minimal.  It's conceivable that the return value of a misused
subtype_diff function could be interesting (think some sort of
decryption function); but the system doesn't offer any way for a user
to see that return value.  It will only factor into GiST index page
split decisions, and in a pretty indirect way at that.  So I don't see
any interesting security risk for a misused subtype_diff function;
and there's not likely to be any meaningful hole for abusing canonical
functions either, due to the restrictions on argument/result datatype.

I still think we ought to add a creation-time permission check, just
for pro-forma purposes.

> 2. The ANALYZE option is flat out dangerous,

But this is still true.

			regards, tom lane

In response to

• Permissions checks for range-type support functions at 2011-11-22 23:38:03 from Tom Lane

pgsql-hackers by date

Next:	From: Pavel Stehule	Date: 2011-11-23 06:44:27
	Subject: Re: dblink: enable parameters
Previous:	From: Tom Lane	Date: 2011-11-23 02:40:48
	Subject: Re: range_adjacent and discrete ranges