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

>>  > I am unclear how hard it would be to allow it to be
>>  > controlled via INSERT, meaning it would be present only if the row had a
>>  > SEC value supplied.
>>
>> It is impossible, and not suitable for SE-PostgreSQL.
>> The HeapTuple is allocated prior to fetch INSERT'ed value.
>> In addition, SE-PostgreSQL assigns its default security context when no
>> security attribute is given.
> 
> When SE-Linux is enabled, couldn't NULL represent the default security
> context?

Yes, users will get the default security context, as if they insert
a tuple without any specific "oid" but proper value is assigned.

>>> Here is our OID column on some rows but not others:
>>>
>>>     test=> CREATE TABLE test (x INT) WITH oids;
>>>     CREATE TABLE
>>>     test=> INSERT INTO test VALUES (1);
>>>     INSERT 16392 1
>>>     test=> ALTER TABLE test SET WITHOUT OIDS;
>>>     ALTER TABLE
>>>     test=> INSERT INTO test VALUES(2);
>>>     INSERT 0 1
>>>     test=> SELECT oid, * FROM test;
>>>     ERROR:  COLUMN "oid" does not exist
>>>     LINE 1: SELECT oid, * FROM test;
>>>
>>> but it has per-table granularity;  the oid value for '1' is still
>>> stored, but is no longer visible;  that would not work for the security
>>> value.
>> If we can control the Row-level ACLs via table options, what should be
>> happen when we turn off the feature?
>> IMO, it is natural to ignore Row-level ACLs independent from whether
>> the stored tuple actually has ACLs, or not.
> 
> Hmmm, sounds like perhaps a GUC is needed there.

Is it possible to control per-table granuality?
Or, per-table control is not necessary?

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