Skip site navigation (1) Skip section navigation (2)

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

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Joshua Brindle <jbrindle(at)tresys(dot)com>
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Date: 2012-01-31 09:36:05
Message-ID: 4F27B605.8080802@gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2012-01-30 19:19, Robert Haas wrote:
> On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGai<kaigai(at)kaigai(dot)gr(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Gilles DaroldDate: 2012-01-31 09:57:42
Subject: Re: Patch pg_is_in_backup()
Previous:From: pratikchiraniaDate: 2012-01-31 09:10:11
Subject: Re: pgstat wait timeout

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group