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

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Robert Haas <robertmhaas(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-03-10 21:35:23
Message-ID: 4F5BC91B.1030004@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2012-03-10 14:06, Robert Haas wrote:
> On Sat, Mar 10, 2012 at 4:39 AM, Yeb Havinga<yebhavinga(at)gmail(dot)com> wrote:
>>> As a separate but related note, the label management here seems to be
>>> excessively complicated. In particular, it seems to me that the
>>> semantics of sepgsql_get_client_label() become quite muddled under
>>> this patch. An explicitly-set label overrides the default label, but
>>> a trusted procedure's temporary label overrides that. So if you enter
>>> a trusted procedure, and it calls sepgsql_setcon(), it'll change the
>>> label, but no actual security transition will occur; then, when you
>>> exit the trusted procedure, you'll get the new label in place of
>>> whatever the caller had before. That seems like one heck of a
>>> surprising set of semantics.
>> I agree that sepgsql_get_*client*_label does not really match with a trusted
>> procedure temporarily changing it.
> I'm not complaining about the name of the function; I'm complaining
> about the semantics.

The semantics are muddled because the client labels are mixed with
labels from trusted procedures. The stack you described upthread may
also exhibit surprising behaviour. If a trusted procedure is called,
it's label is pushed onto the stack. Suppose it pushes another label by
calling sepgsql_setcon(). In the stack case, this is now the top of the
stack and the result of sepgsql_get_client_label(). The procedure
exists. What should now be the result of sepgsql_get_client_label()?
Since labels are managed by a stack, we can only pop what's on top and
need to pop twice, so we've lost the label pushed onto the stack by the
trusted function, which means that trusted procedures cannot be used to
change client labels beyond their own scope, but other functions would.

Maybe this semantics muddling of trusted procedures and setting the
client label can be avoided by denying changing the client label with
sepgsql_setcon() from a trusted procedure, which would also make some sense:

ERROR: cannot override the client label of a trusted procedure during
execution.

--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-03-10 22:39:25 about EncodeDateTime() arguments
Previous Message Stefan Keller 2012-03-10 21:35:14 Re: pg_prewarm