>> > 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>