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

Bruce Momjian wrote:
> Second, system catalogs; are you going to have separate columns for
> SQL-level row security and SE-Linux security? If so, is the SE-Linux
> column only going to be created by the --enable-selinux build? If so,
> that is going to mean that the /data directory is going to be affected
> by the --enable-selinux flag, which is not ideal --- it would be good if
> someone could switch to an SE-Linux binary without to dump/reload. One
> nice idea would be to have one "security" column and allow both
> SQL-level and SE-Linux security values to be stored in the column,
> perhaps at the same time; that way there is no new column needed for
> SE-Linux.
>
> I know I suggested the security column act like the system oid column,
> but now I am thinking I was wrong. The system oid column stores an
> auto-generated value so it was necessary to have it be specified at
> CREATE TABLE time because it is guaranteed to take storage space. For
> the security column, in most cases it will be null, meaning it would not
> take any storage space becuase we use a null bitmap for null column
> values. So, perhaps the security column should be in every table and we
> can just make it default to null; I think that would give us much more
> flexibility to add security to existing tables.

Sorry, I am confusing system columns, like pg_class.relname, with
user-table system columns, like mytable.xmin. I don't think we have the
ability of having user-table system columns nullable, right?

We do have a per-row HEAP_HASOID bit, so I wonder if we can have a
HEAP_HASSEC bit too. Right now the HEAP_HASOID is controlled by the
CREATE/ALTER table; 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.

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.

The complexity is that the column would always exist (unlike OID), but
would be NULL if not assigned to. This would allow any table to have
security by default, and have no overhead if security is not defined for
the row. Now, I realize SE-Linux would have security defined for each
row, but SQL-level row security might not, and this would allow the
feature to be very useful, perhaps with a GUC that required security for
SE-Linux, and /data would be the same for SE-Linux and non-SE-Linux. If
we could make the row behave like this we might use separate columns for
SQL-level and SE-Linux security because there would be no storage
overhead unless security was used.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +