On 2012-03-10 14:06, Robert Haas wrote:
> On Sat, Mar 10, 2012 at 4:39 AM, Yeb Havinga<yebhavinga@gmail.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