On 2012-01-30 19:19, Robert Haas wrote:
> On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGai<kaigai@kaigai.gr.jp> wrote:
>> 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.)
> Of course, we already have a trusted procedure mechanism which is
> intended to support temporary changes to the effective security label,
> so you might say, hey, people shouldn't do that. But they might. And I
> wouldn't like to bet that's the only case that could be problematic
> either. What about a setting in postgresql.conf? You could end up
> being asked to set the security label to some other value before
> you've initialized it. What about SET LOCAL? It's not OK to fail to
> revert that at transaction exit. Hence my suggestion of a function: if
> you use functions, you can implement whatever semantics you want.
What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the
transition to this domain is hardcoded to succeed. This would also be
useful in conjunction with a connection pooler. This would still allow
the option to prevent a back transition to non-default client labels.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data