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.60...@ak.jp.nec.com
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
