Re: simply custom variables protection - Mailing list pgsql-patches

From Tom Lane
Subject Re: simply custom variables protection
Date
Msg-id 10708.1175968944@sss.pgh.pa.us
Whole thread Raw
In response to Re: simply custom variables protection  ("Pavel Stehule" <pavel.stehule@hotmail.com>)
List pgsql-patches
"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
>> How does a user protect a custom variable using your code?  I don't see
>> any API that would allow that.

> Every module is responsibile for protectiong own custom variables. Only
> module knows if some variable needs protection. And after module
> inicialisation module can call ArmorCustomVariable function. From this
> moment only superuser can modify this custom variable. If it call
> ResetPGVariable() function before then default value is protected.

Well, that's the other problem with this approach: the variable is
protected only against changes occurring *after* ArmorCustomVariable
is called.  Throwing away the existing value using ResetPGVariable is
surely undesirable if the existing value was in fact set by a superuser.
What's worse, I think it is a security hole, because ResetPGVariable's
effects can be rolled back by aborting the transaction in which the
module load occurs.

In any case we've now got a three-step rather than one-step method
for setting up a custom variable, with various interesting failure
modes if you do the steps in the wrong order.  This is not a clean
solution.

            regards, tom lane

pgsql-patches by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: simply custom variables protection
Next
From: Tom Lane
Date:
Subject: Re: LIMIT/SORT optimization