> * ACL_INSERT > The db_table:{insert} and db_column:{insert} for all the target > columns are checked. The table-level permission does not override > column-level permission, so the client need to have privileges > for both of objects. It is same as other permissions. > > * ACL_SELECT > The db_table:{select} and db_column:{select} for all the target > columns are checked. > But it applies db_table:{lock} on LockTableCommand(). > > * ACL_UPDATE > The db_table:{update} and db_column:{update} for all the target > columns are checked. > > * ACL_DELETE > The db_table:{delete} is also checked. No column-level checks here.
I'm more or less with you up to this point. > * ACL_TRUNCATE > The db_table:{delete} is also checked. > SE-PostgreSQL does not discriminate between TRUNCATE and DELETE. But this seems wrong. > * ACL_REFERENCES > * ACL_TRIGGER > SE-PostgreSQL does not care about these privileges. > But, it checks db_procedure:{execute} on trigger invocation time, > and it also checks db_table:{select} on checks of FK constraint > within its secondary SQL execution. And so do these. Why should there be any asymmetry with regular PostgreSQL here? > * ACL_EXECUTE > The db_procedure:{execute} is also checked. > This check is embedded within pg_proc_ackcheck(). Good... > * ACL_USAGE > * ACL_CREATE > * ACL_CREATE_TEMP > SE-PostgreSQL does not care about there privileges. Again, there doesn't seem to be any reason for this asymmetry. I think you should change it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers