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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
