Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) - Mailing list pgsql-hackers

KaiGai Kohei wrote:
> 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,

It is fine if you require SECEXT to be on for SE-Linux, but the option
must be available for non-SE-Linux so you can load dumps from either
Postgres configuration, and /data is compatible with both versions.

> > 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 you make an SE-Linux dump with security fields, how will that be
loadable in a non-SE-Linux Postgres database?

We are also going to need ALTER TABLE to be able to add/remove these
columns from tables, like OIDs.

>  >> If we assume users set up Row-level ACLs for specific tables, per-table
>  >> option is meaningful for reduction of NULL-bitmap space in the tuple
>  >> without any NULL-values on general columns.
>  >
>  > Right.  I was hoping there was a way to have HEAP_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.

I am confused why we would want this instead of the way we do oids.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +