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

2012/3/9 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Tue, Mar 6, 2012 at 9:14 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> [ new patch ]
>
> Are we absolutely certain that we want the semantics of
> sepgsql_setcon() to be transactional?  Because if we made them
> non-transactional, this would be a whole lot simpler, and it would
> still meet the originally proposed use case, which is to allow the
> security context of a connection to be changed on a one-time basis
> before handing it off to a client application.
>
I hesitate to implement sepgsql_setcon() being not-transaction aware,
because any other functionality are all transaction aware, such as
SECURITY LABEL statement.
Even though the original use-case from Joshua does not require it
being transaction-aware, I'd like to keep consistency of behavior
with any other features. Is it really unacceptable complexity?

> It seems to me that it would make more sense to view the set of
> security labels in effect as a stack.  When we enter a trusted
> procedure, it pushes a new label on the stack; when we exit a trusted
> procedure, it pops the top label off the stack.  sepgsql_setcon()
> changes the top label on the stack.  If we want to retain
> transactional semantics, then you can also have a toplevel label that
> doesn't participate in the stack; a commit copies the sole item on the
> stack into the toplevel label, and transaction start copies the
> toplevel label into an empty stack.  In the current coding, I think
> client_label_peer is redundant with client_label_committed - once the
> latter is set, the former is unused, IIUC - and what I'm proposing is
> that client_label_func shouldn't be separate, but rather should mutate
> the stack of labels maintained by client_label_pending.
>
I almost agree with your opinion. A semantics to stack security label
will be more straight-forward.

One reason of the redundant client_label_peer is to support reset
client label using NULL-input on sepgsql_setcon(). We need to save
the original value somewhere.

In case of sepgsql_setcon() being invoked inside of the trusted-
procedure, indeed, the existing behavior is confusing as you pointed
out. If we would changed the semantics using a stack structure,
an invocation of trusted procedure takes a label transition from A to B,
then it invokes sepgsql_setcon() to take a label transition from B to C,
and the label "B" shall be popped from the stack at end of the trusted
procedure. Eventually, the label "C" shall be applied on top of the stack.
Do we share same image to whole of the idea?

> The docs need updating, both to reflect the version bump in
> sepgsql-regtest.te and to describe the actual feature.
>
OK, please wait for a few days.

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