Re: [v9.2] Add GUC sepgsql.client_label

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