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>