On Tue, Jan 31, 2012 at 9:10 AM, Yeb Havinga <yebhavi...@gmail.com> wrote: > On 2012-01-31 14:06, Robert Haas wrote: >> On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga<yebhavi...@gmail.com> wrote: >>> >>> 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. >> >> I don't think you can make that work, because someone can still >> attempt to RESET to a different value, and it's still not safe to make >> that fail. > > But the idea is that if that different value is a (possibly changed into a > new) allowed default value, a RESET to that new default value will be > allowed, by definition, because it is a default value.
*scratches head* I'm not sure I follow you. If you're saying that we can make this work by always allowing the value to be reset, then I agree with you, but I'm not sure those are the semantics KaiGai wants. For instance, if a connection pooler does: SET sepgsql.client_label = 'bob_t'; ...and then hands off to the client, the client can then do: RESET sepgsql.client_label; SET sepgsql.client_label = 'alice_t'; ....and that's bad. More generally, the system security policy is designed to answer questions about whether it's OK to transition from A->B, and the fact that A->B is OK does not mean that B->A is OK, but our GUC mechanism pretty much forces you to allow both of those things, or neither. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
