Re: Permissions checks for range-type support functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Permissions checks for range-type support functions
Date: 2011-11-23 03:28:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

Browse pgsql-hackers by date

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