Re: Prep object creation hooks, and related sepgsql updates

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 <kaigai@kaigai.gr.jp>:
> 2011/11/28 Dimitri Fontaine <dimitri@2ndquadrant.fr>:
>> Kohei KaiGai <kaigai@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 <kaigai@kaigai.gr.jp>

--
KaiGai Kohei <kaigai@kaigai.gr.jp>