I tried to implement remaining portion of the object creation permission patches using this approach; that temporary saves contextual information using existing ProcessUtility hook and ExecutorStart hook.
It likely works fine towards my first problem; system catalog entry does not have all the information that requires to make access control decision. In the case of pg_database catalog, it does not inform us which database was its source. Also it maybe works towards my second problem; some of code paths internally used invokes object-access-hook with OAT_POST_CREATE, so entension is unavailable to decide whether permission checks should be applied, or not. In the case of pg_class, heap_create_with_catalog() is invoked by make_new_heap(), not only DefineRelation() and OpenIntoRel(). So, this patch checks which statement eventually calls these routines to decide necessity of permission checks. All I did is a simple hack on ProcessUtility hook and ExecutorStart hook, then post-creation-hook references the saved contextual information, as follows. sepgsql_utility_command(...) { sepgsql_context_info_t saved_context_info = sepgsql_context_info; PG_TRY() { sepgsql_context_info.cmdtype = nodeTag(parsetree); : if (next_ProcessUtility_hook) (*next_ProcessUtility_hook) (....) else standard_ProcessUtility(....) } PG_CATCH(); { sepgsql_context_info = saved_context_info; PG_RE_THROW(); } PG_END_TRY(); sepgsql_context_info = saved_context_info; } Then, sepgsql_relation_post_create(....) { : /* * Some internally used code paths call heap_create_with_catalog(), then * it launches this hook, even though it does not need permission check * on creation of relation. So, we skip these cases. */ switch (sepgsql_context_info.cmdtype) { case T_CreateStmt: case T_ViewStmt: case T_CreateSeqStmt: case T_CompositeTypeStmt: case T_CreateForeignTableStmt: case T_SelectStmt: break; default: /* internal calls */ return; } : } At least, it is working. However, it is not a perfect solution to the future updates of code paths in the core. Thanks, 2011/11/29 Kohei KaiGai <kai...@kaigai.gr.jp>: > 2011/11/28 Dimitri Fontaine <dimi...@2ndquadrant.fr>: >> Kohei KaiGai <kai...@kaigai.gr.jp> writes: >>> I found up a similar idea that acquires control on ProcessUtility_hook and >>> save necessary contextual information on auto variable then kicks the >>> original ProcessUtility_hook, then it reference the contextual information >>> from object_access_hook. >> >> In this case that would be an INSTEAD OF trigger, from which you can >> call the original command with EXECUTE. You just have to protect >> yourself against infinite recursion, but that's doable. See attached >> example. >> > Hmm... In my case, it does not need to depend on the command trigger. > Let's see the attached patch; that hooks ProcessUtility_hook by > sepgsql_utility_command, then it saves contextual information on auto > variables. > > The object_access_hook with OAT_POST_CREATE shall be invoked > from createdb() that was also called by standard_ProcessUtility. > In this context, sepgsql_database_post_create can reference > a property that is not contained withint pg_database catalog > (name of the source database). > > At least, it may be able to solve my issues on hooks around object > creation time. > > Thanks, > -- > KaiGai Kohei <kai...@kaigai.gr.jp> -- KaiGai Kohei <kai...@kaigai.gr.jp>
pgsql-v9.2-sepgsql-create-permissions-part-1.database.patch
Description: Binary data
pgsql-v9.2-sepgsql-create-permissions-part-4.proc.patch
Description: Binary data
pgsql-v9.2-sepgsql-create-permissions-part-3.relation.patch
Description: Binary data
pgsql-v9.2-sepgsql-create-permissions-part-2.namespace.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers