Tom Lane wrote: > Bruce Momjian <br...@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.
Yep, no question. The two-column idea happened because ignoring the rowacl value for SE-Linux seemed wrong, but I am fine with it. > 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. True. > 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. Yes, an SE-Linux compile could throw errors for those commands. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
