Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Oct 8, 2011 at 12:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The reason that the specific variables you mention (as well as some
>> others that bear on such things) are USERSET and not SUSET is precisely
>> that we are not trying to constrain the amount of resources an
>> uncooperative user can consume. �If we did try to do that, quite a
>> lot of design decisions would have to be revisited, and there would
>> be a number of unpleasant tradeoffs to be made. �GUC privilege levels
>> are just the tip of the iceberg.
> Yeah. For example, if somebody writes a complicated query against a
> gigantic table that runs for a long time, is that because they're
> trying to DOS the server, or because they have a legitimate need for
> the results of that query, and it just so happens to be an expensive
> query? That's not really a question a computer can answer, and if you
> restrict users to running only queries that are so short and simple
> that they can't be used to DOS the box, you'll likely also be locking
> out a significant percentage of legitimate user needs.
Rereading the original message, I see that Josh raised an independent
point which I failed to see was independent. Namely, that if one has
a SECURITY DEFINER function that relies on random() producing
unpredictable values, then an unprivileged user might be able to
compromise the behavior of the function by issuing SET SEED just before
calling the function. That does seem like a potential security issue
--- not a very big one, but still undesirable. And unlike other GUCs
that might affect query behavior, a SECURITY DEFINER function can't
protect itself against such a thing by adding SET clauses, because
setting the seed to a known value is exactly what it doesn't want.
I still don't think that a specialized GUC assignment privilege is worth
the trouble, but I could see an argument for just changing the seed GUC
from USERSET to SUSET.
regards, tom lane