> 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 <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
