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

Bruce Momjian wrote:
>>> Have we decided if we are going to use some type of integer on every row
>>> that points to a pg_security row or put the value right in the row?
>> The reason why I decided to put an integer value on HeapTupleHeader,
>> as "oid" doing, is that it has to be modified after simple_heap_insert()
>> or ExecInsert(). It has to be fixed length and not a user data.
> 
> Ah, so you found a way so the column can be optionally used and does not
> have to be specified for the entire table using a CREATE TABLE option? 
> Great.

The security system column is always generated.
But it is independent from whether the tuple allocate its security field
on the HeapTupleHeader, or not.

The Row-level ACL stores a flag within pg_class.reloptions, and it shows
whether the Roe-level ACL is available, or not.
When we refer the security system column on the table being unavailable,
it returns a dummy data (empty text) because tuples does not have security
field.

SE-PostgreSQL does not allow owner to control it per-table due to its
security design.

Is it appropriate for the answer?

>>> Also, having the per-row value always be present in the row and
>>> controlled by the bitmask seems ideal;  it avoids having to add a CREATE
>>> TABLE option.
>> Sorry, I don't understand why it related to a CREATE TABLE option.
>> System columns are always allocated for any tables?
> 
> Does a table use storage for the security column if no SQL-level
> security value is supplied for a given row?

When Row-level ACL is enabled on the table and user suppies a tuple
without any specific ACLs, it requires security field, because the
length of HeapTuple is decided at heap_form_tuple() which is invoked
prior to fetching the user supplied ACLs.

When Row-level ACL is disabled (by pg_class.reloptions) on the table,
the storage for security field is not necessary.

> Also what patch version should I be looking at.  How will that version
> need to be changed?

As I promised, the patch ready for reviewing must allow to compile multiple
security mechanisms, and to choose one of them on startup.
(The current latest r1280 use approach to enable/disable on compile-time.)

Could you wait for a few days to provide newer version.

The following list is the items to be revised:  http://archives.postgresql.org/message-id/4941C690.60803@ak.jp.nec.com

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>