Re: security hook on table creation

(2010/10/12 11:35), Robert Haas wrote:
> 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.
>
It enables us to put security hooks independent from MVCC visibility of
the new database object. If we pay attention for visibility of new database
object, it seems to me amount of things to understand and maintain will be
increased, although MVCC visibility is fundamentally unrelated stuff from
viewpoint of the access control.

In the idea of two hooks, the prep-creation hook shall be invoked in same
visibility of existing permission checks, and the post-creation hook shall
be invoked in same visibility of simple_heap_* operations.
I think it enables to reduce amount of things to understand and maintain,
because the scope we should pay attention become small, if we can put
security hooks independent from MVCC visibility.

Perhaps, the problem may be intangible, but I don't think it is fair
enough if we have to pay attention about MVCC visibility of plugin
modules whenever we try to apply a patch around creation hooks.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>