From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |
Date: | 2008-12-12 06:09:37 |
Message-ID: | 49420021.8060400@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2008-12-12 06:16:13 | Re: V2 of PITR performance improvement for 8.4 |
Previous Message | Bruce Momjian | 2008-12-12 05:36:34 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |