2012/3/12 Robert Haas <robertmhaas@gmail.com>:
> On Mon, Mar 12, 2012 at 12:30 PM, Kohei KaiGai <kaigai@kaigai.gr.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.
>
OK, I try to update the documentation and test cases with related
security policy, rather than the code base itself.
Please wait for a few days to update them.
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
