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