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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Gilles Darold | 2012-01-31 09:57:42 | Re: Patch pg_is_in_backup() |
Previous Message | pratikchirania | 2012-01-31 09:10:11 | Re: pgstat wait timeout |