2012/1/26 Robert Haas <robertmhaas@gmail.com>:
> On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> 2012/1/26 Robert Haas <robertmhaas@gmail.com>:
>>> I'm wondering if a function would be a better fit than a GUC. I don't
>>> think you can really restrict the ability to revert a GUC change -
>>> i.e. if someone does a SET and then a RESET, you pretty much have to
>>> allow that. I think. But if you expose a function then it can work
>>> however you like.
>>>
>> One benefit to use GUC is that we can utilize existing mechanism to
>> revert a value set within a transaction block on error.
>> If we implement same functionality with functions, XactCallback allows
>> sepgsql to get control on appropriate timing?
>
> Not sure, but I thought the use case was to set this at connection
> startup time and then hand the connection off to a client. What keeps
> the client from just issuing RESET?
>
In the use case of Joshua, the original security label does not privileges
to reference any tables, and it cannot translate any domains without
credential within IC-cards. Thus, RESET is harmless.
However, I also assume one other possible use-case; the originator
has privileges to translate 10 of different domains, but disallows to
revert it. In this case, RESET without permission checks are harmful.
(This scenario will be suitable with multi-category-model.)
Apart from this issue, I found a problem on implementation using GUC
options. It makes backend crash, if it tries to reset sepgsql.client_label
without permissions within error handler because of double-errors.
So, I'll try to modify the patch with an idea to use a function.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
