From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SE-PostgreSQL Specifications |
Date: | 2009-07-24 23:45:47 |
Message-ID: | 20090724234547.GF5407@samason.me.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-07-25 00:08:13 | Re: COPY WITH CSV FORCE QUOTE * -- REVIEW |
Previous Message | Tom Lane | 2009-07-24 23:39:11 | Re: Non-blocking communication between a frontend and a backend (pqcomm) |