Bruce Momjian <bruce@momjian.us> writes:
> Let me outline the simplest API, assuming we are using table-level
> granularity for the security columns.
> CREATE TABLE would support
> WITH (ROWACL = TRUE/FALSE);
> for row-level acl and:
> WITH (SECEXT = TRUE/FALSE);
> for SE-Linux, with 'SECEXTL' standing for SECurity EXTernal or
> SECurity_contEXT.
Wait a minute. The original argument for providing SQL-driven row level
security was that it would help provide a framework for testing the code
and doing something useful with it on non-selinux platforms. Now we
seem to be proposing two independent implementations --- which, even
if similar, could still suffer different bugs (due to copy-and-pasteos
if nothing else). So the testing argument goes right out the window.
Also, this is getting even further afield from any capability that
anyone actually asked for.
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Otherwise you're
making a lie of the primary argument for having the SQL feature at all.
It's possible that some people would want to insist that only selinux
be used to manipulate the settings, but I think that could be addressed
by a compile-time option to disable the SQL commands.
regards, tom lane
