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

>> 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.

It is unclear for me why you thought this option is necessary to load
dumps generated by vanilla PostgreSQL?
I assumes the security column should be always available, so we don't
need to add a column when SE-PostgreSQL load a vanilla $PGDATA.

>>> 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?

In this case, user should no dump his database with security field.
The patched pg_dump does not dump security field without
'--security-context' option.

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

I don't agree.
The "security column" (not a "acl column") should be always exist.
In the vanilla binary, it simply returns NULL or empty string, so there is
no waste of storage consumption.
It is worthful when we run SE- binary with $PGDATA generated by vanilla one.
Any stored tuple does not have security field, but it gives DBAs a chance to
relabel them via the "security column".

>>  >> 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.

It enables to implement the hardcoded row-acl more simple.
It allows to store variable length ACLs using existing mechanism, and
makes unnecessary to translate between ACLs and raw text representation.


Thanks,