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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
