I'd like to see opinions what facilities should be developed to the current v9.1 development cycle.
We have integrated some of facilities to support a starter- version of SE-PostgreSQL. It allows to hook controls on DML permission checks and assign security labels of client and database obejcts either by-hand or automatically. On the other hand, hooks on DDL permission checks are still future works from now. I believe object_access_hook is applied on various kind of DDL permission checks, but we cannot complete to put these hooks at once, because of patch scale. So, I plan to integrate the following four facilities only in the last commit-fest of v9.1, although it still does not cover comprehensive DDL accesses . * Expand object_access_hook to deliver arguments Some of DDL hooks will need to deliver several arguments in addition to OID of the object being modified. For example, a flag to show whether this deletion is cascaded, or not. So, prototype of the object_access_hook needs to be revised. My idea is to add two arguments: an integer variable for number of arguments and an array variable for the additional information. Then, macros will wrap up invocation of this hook to keep the code simple. * Permission checks on object-prep-creation It was not well concluded in the previous discussion, whether two hooks are needed, or one. I think the idea to divide creation hooks into two phases by its role eventually enables to reduce the burden of code management. Now we have OAT_POST_CREATE hooks just after registration of dependency, basically. It is a simple enough basis, and quite natural places to assign new security labels. However, several cases shall be exceptions of the basis, if we try to check permissions also in the post-creation hooks, in addition to default labeling. For example, heap_create_with_catalog() is called from five places, but only two needs permission checks: DefineRelation() and OpenIntoRel(). A few cases are not obvious whether we need permission checks in this invocation, like a code path from make_new_heap(). It defines a new pg_class entry, but the external module cannot determine from the catalog whether is is invoked on the code path that needs permission checks, or not. So, I want OAT_CREATE hooks being just after existing permission checks for the purpose of access control, not default labeling. * Permission checks on object-deletion The existing code put permission checks of object deletion on command handlers like RemoveRelations(), then it invokes functions in dependency.c to drop the specified and dependent objects (if necessary). I think it is straight-forward to put object-deletion hooks next to the existing permission checks. But it is unavailable to check cascaded objects to be removed here. So, it seems to me findDependentObjects() should be exposed to external modules to inform what objects shall be dropped. Unlike old SE-PostgreSQL implementation, I don't consider it is a good idea to put hook within dependency.c, because we need to inform dependency.c whether this deletion is by-hand, or something internals (such as cleanups of temporary objects). * Permission checks on misc easy implementables Apart from the priority of development, it seems to me that we can hook controls at the following commands quite easy. It is an idea to put hooks that we can implement with little impact around the existing codes. - GRANT/REVOKE - COMMENT ON - SECURITY LABEL Thanks, -- KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
