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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Yeb Havinga <yebhavinga(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 14:28:38
Message-ID: CA+TgmoaNTbthUyoX7fmuyztF=75+ONF=y+tM+CeOA8BXVcm9aA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Jan 31, 2012 at 9:10 AM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
> On 2012-01-31 14:06, Robert Haas wrote:
>> On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga<yebhavinga(at)gmail(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2012-01-31 14:35:03
Subject: Re: JSON for PG 9.2
Previous:From: Robert HaasDate: 2012-01-31 14:24:45
Subject: Re: Group commit, revised

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