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

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-09 20:09:43
Message-ID: 4F5A6387.8050303@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2012-03-06 15:14, Kohei KaiGai wrote:
> In case of sepgsql_setcon() being invoked with null argument
> to reset security label of the client, but not committed yet,
> the last item of the client_label_pending has null label.
> (It performs as a mark of a security label being reset.)
Yes, I see that now. Another solution could be to append
client_label_peer on the pending list instead of NULL, but maybe this is
not important enough to discuss. I tried to do some testing by first
transition into a smaller MLS context, then reset to the original again,
but that is not allowed by the regtest policy. I searched the internet
for 30 minutes about how to write a allow rule that would allow e.g. the
transition from c1.c4 back to c1.c1023 but failed.

two other minor nitpicks

-- * contrib/sepgsql/label.c
-+ * contrib/sepgsqlet/label.c

typo here..

-+ /* Append the supplied new_label on the pending list. */
++ /*
++ * Append the supplied new_label on the pending list until
++ * the current transaction is committed.
++ */

the 'until the current transaction is committed' part is something going
on outside of sepgsql_set_client_label() - this function just appends to
the list, always. That the list is reset on transaction commit/abort
time, is done and also already documented elsewhere. A new reader could
be confused to not find transaction related things in
sepgsql_set_client_label().

regards,
Yeb

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-03-09 20:09:47 Re: poll: CHECK TRIGGER?
Previous Message Robert Haas 2012-03-09 20:08:07 Re: Is it time for triage on the open patches?