Re: security hook on table creation

On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> It seems to me the conclusion of this discussion is unclear.
>
> We commonly try to find out an approach that minimize code complexity
> to understand and maintain, so the point of issue is clear, but we
> still don't reach same conclusion, because both of two ideas have merits
> and demerits each other.
>
> * Prep/Post-creation hook
>  merits: simple principle to deploy security hooks. The prep-creation
>    hook shall be after existing DAC checks, and the post-creation hook
>    shall be after modification of system catalogs.
>  demerits: several specific security hooks are necessary, in addition
>    to the main security hook.
>
> * Only post-creation hook
>  merits: small number of security hook definitions.
>  demerits: at least, new entries of system catalog must be visible
>    when we invoke the security hooks, so some cases require us to
>    add new CCIs on invocations, but it requires us to verify it is
>    harmless (whenever we will touch the code around security hooks
>    in the future).
>
> In my viewpoint, MVCC is one of the most complex things in PG.
> So, in fact, I also missed the possibility that the gust of security
> hook cannot reference the entry of new database object, when the idea
> of post-creation hook was suggested.
> If we have a strong (and implicit) restriction about places where
> we should deploy the security hooks on, I don't think it enables to
> minimize our task to understand and maintain (in the future), although
> line of change set is a bit smaller now.
>
> So, I think the idea of two hooks on creation is better.
> It tries to put prep-creation hook according to the manner of existing
> DAC checks, and post-creation hook is next to modification of system
> catalogs with same visibility of the main entries.
> It seems to me this simple principle enables to minimize our task to
> understand and maintain.

I don't understand what problem you think having two hooks will solve.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company