Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

Bruce Momjian wrote:
> Bruce Momjian wrote:
>> KaiGai Kohei wrote:
>>>>>    CREATE TABLE t (
>>>>>        a   int,
>>>>>        b   text
>>>>>    ) WITH (ROW_LEVEL_ACL=ON);
> 
> Let me outline the simplest API, assuming we are using table-level
> granularity for the security columns.
> 
> CREATE TABLE would support
> 
>     WITH (ROWACL = TRUE/FALSE);
> And then in postgresql.conf we would have:>>     default_with_rowacl

Yes, I agree it.

But SE-PostgreSQL does not need its table option to control
its availability per table granuality due to its security model.

Database ACL is a kind of DAC. It allows resource owners to
set up its access rights. In other hand, SE-PostgreSQL is an
implementation of MAC. It does not allow owners to control its
access rights. This is the role of centralized security policy,

> When SE-Linux is enabled, CREATE TABLE would issue an error if SECEXT
> was false.  I can't think of a clean way to guarantee that existing
> tables have SECEXT though, which means we might need to have a missing
> 'security_context' column mean default SE-Linux permissions.

SE-PostgreSQL stores its security context on the security field of
HeapTupleHeader and set HEAP_HASSECURITY of t_infomask.
The security system column is always available, so it does not make
any matter. When no guest is available on PGACE, HEAP_HASSECURITY of
t_infomask is not set, so security field is not allocated and NULL
bitmask is not polluted.
>> If we assume users set up Row-level ACLs for specific tables, per-table>> option is meaningful for reduction of
NULL-bitmapspace in the tuple>> without any NULL-values on general columns.>> Right.  I was hoping there was a way to
haveHEAP_HASSECACL control if> the value is present or not.>> I sure wish others were adding ideas to this discussion.
 

I have a plan to add a new field (declared as "int2 relrowacl") into
pg_class to show what column stores its Row-level ACLs.
When we create a table with (ROWACL=TRUE), it implicitly add a column
declared as "security_acl aclitem[]", and its attribute number is
stored within the "pg_class.relrowacl". If it has positive value,
tuples within the table can have its individual ACLs. No-ACL is
represented via the NULL-bitmap. If it is zero, the table does not
have the "security_acl" column, and the row-level controls are simply
ignored.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>