Skip site navigation (1) Skip section navigation (2)

Re: Prep object creation hooks, and related sepgsql updates

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Prep object creation hooks, and related sepgsql updates
Date: 2011-12-02 11:52:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
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_context_info_t  saved_context_info = sepgsql_context_info;

        sepgsql_context_info.cmdtype = nodeTag(parsetree);
        if (next_ProcessUtility_hook)
            (*next_ProcessUtility_hook) (....)
        sepgsql_context_info = saved_context_info;
    sepgsql_context_info = saved_context_info;


     * 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:
            /* internal calls */

At least, it is working. However, it is not a perfect solution to the
future updates
of code paths in the core.


2011/11/29 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> 2011/11/28 Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>:
>> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Attachment: pgsql-v9.2-sepgsql-create-permissions-part-1.database.patch
Description: application/octet-stream (10.1 KB)
Attachment: pgsql-v9.2-sepgsql-create-permissions-part-4.proc.patch
Description: application/octet-stream (5.7 KB)
Attachment: pgsql-v9.2-sepgsql-create-permissions-part-3.relation.patch
Description: application/octet-stream (14.4 KB)
Attachment: pgsql-v9.2-sepgsql-create-permissions-part-2.namespace.patch
Description: application/octet-stream (4.1 KB)

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-12-02 13:01:06
Subject: Re: WIP: Join push-down for foreign tables
Previous:From: Alexander KorotkovDate: 2011-12-02 11:48:59
Subject: Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group