> Bruce Momjian <[EMAIL PROTECTED]> 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.
Yes, In addition, I want folks to remind that the Row-level ACLs are not designed based on SQL standards. Thus, I called it one of the enhanced securities. > 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. My original opinion is that users should be able to choose what enhanced security mechanism is available on his system. In all honesty, I don't understand why the Row-level ACLs has privileged position in the enhanced securities and it should be always available. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
