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

On Mon, Mar 12, 2012 at 12:30 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> Suppose that the connection starts out in context connection_pooler_t.
>>  Based on the identity of the user, we transition to foo_t, bar_t, or
>> baz_t.  If it's possible, by any method, for one of those contexts to
>> get back to connection_pooler_t, then we've got a problem.  We give a
>> connection to user foo which is in foo_t; he transitions it back to
>> connection_pooler_t, then to bar_t, and usurps user bar's privileges.
>> Unless there's some way to prevent that, the only way to make this
>> secure is to make the transition to foo_t irreversible.
>>
> It is the reason why I advocate the idea to allow sepgsql_setcon()
> inside of trusted-procedures.
>
> The original use-case of Joshua does not allow connection_pooler_t
> to execute any SQL commands except for invocation of a particular
> trusted-procedures; that takes a secret credential as an argument,
> then it switches the client label to foo_t, bar_t or baz_t according to
> the supplied credential.
> These labels are allowed to switch back to the original
> connection_pooler_t, but it is unavailable to switch arbitrary label
> without suitable credential.

Oh, I get it.

Given that that's the intended use case, the current design does make
sense, but it seems awfully special-purpose. Not knowing that this is
what you had in mind, I never would have guessed the reason for all
this complexity. I worry that this is too much of a purpose-built
mechanism, and that nobody will ever be able to use it for much of
anything beyond the extremely specific use case that you've laid out
here. I think that, at the very least, the comments and documentation
need to make it clear that this is very deliberately intended to
modify only the toplevel security context of the session, which may be
different from the currently active context if a TP is in use; and
also that the change will apply to future transactions only if the
current transaction commits.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company