On 2012-01-30 19:19, Robert Haas wrote:
On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGai<kai...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
