On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote: > Thanks, but I found an incorrect change at the trusted procedure section. > > Old) > CREATE TABLE customer ( > cid integer primary key, > cname varchar(32), > credit varchar(32) > - SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0' > - ); > > New) > CREATE TABLE customer ( > cid integer primary key, > cname varchar(32), > credit varchar(32) > + ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'; > > This example intends to assign "secret" label on the credit column, > not whole of the table. Note that the default security context shall > be assigned on the table and rest of columns in this case.
The show_credit() function in this section would seem to leak authority as well; it seems possible to determine if customers exist that otherwise may otherwise hidden. For example, imagine we have a row in the customer table with cid=1 whose security label would normally prevent. We can perform: SELECT show_credit(1); and, as far as I can tell, this call would succeed. -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
