On Sat, Mar 10, 2012 at 4:35 PM, Yeb Havinga <yebhavi...@gmail.com> wrote:
> 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.

What I was proposing is that it would *replace* the label on top of 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,

The above avoids the 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.

That's true, but I'm not convinced it's bad.  I mean, if you instruct
the system to change security labels for the duration of a trusted
procedure, then it shouldn't be surprising that you end up with the
same security label after it exits that you had before entering it.
At the very least, it has the virtue of being consistent with other
things, like how GUCs behave.  The current behavior is that you change
the context and you don't see the results of your own context change,
which seems far worse.

> 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.

That also seems possibly reasonable.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to