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

2012/3/11 Yeb Havinga <yebhavinga(at)gmail(dot)com>:
> On 2012-03-10 10:39, I  wrote:
>
>>
>> I can probably write some docs tomorrow.
>>
>
> Attached is v5 of the patch, with is exactly equal to v4 but with added
> documentation.
>
Thanks for your dedicated volunteer. I'm under checking of the updates
at documentation.

> Some other notes.
>
> - Robert asked why sepgsql_setcon with NULL to reset the value to the
> initial client label was supported. Maybe this could be a leftover from the
> initial implementation as GUC variable?
>
It is a practical reason. In case when httpd open the connection to PG and
set a suitable security label according to the given credential prior to launch
of user application, then keep this connection for upcoming request, it is
worthwhile to reset security label of the client.

> - earlier I suggested preventing setting a new client label from a trusted
> procedure, however I just read in the original post that this was how the
> current usecase of Joshua is set up. Suggestion withdrawn.
>
In the scenario of Joshua's security policy, it does not allow httpd to issue
SQL commands except for the trusted procedure that calls sepgsql_setcon()
according to the given credential. (Thus, we have no way to set an arbitrary
security label without credentials.) The security label being switched is
allowed to issue SQL commands with restricted privileges, and also allows
to translate into httpd's domain.
If we would not support sepgsql_setcon() in trusted procedure, we have to
allow httpd to translate an arbitrary label thus it also disallow to keep
connection because it should not revert the client label to httpd (it means
"restricted" users enable to switch someone arbitrary!)

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>