Re: security hook on table creation

(2010/10/12 20:59), Robert Haas wrote:
> 2010/10/11 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>> 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.
>
> This may be nothing more than a matter of opinion, but it seems to me
> that what you're proposing makes this vastly more complicated for no
> particular benefit.  Instead of having one hook that can cover a wide
> variety of use cases, you're going to need individual hooks for each
> object type plus the ability to pass data between them.

In the broad outline, I also agree with one main security which can
cover most of use cases. However, the only difference is that I'm
saying we should handle prep-creation case as exception of the main
hook.
As I introduced before, the idea of two hooks makes obvious where
we should put the security hooks; it is next to the existing DAC
checking. It is the best guideline, even if we will touch the code
around object creation in the future version.

If the creation-hook would be put on the place far from existing
DAC checks, what provides us a guideline to deploy security hooks?
It seems to me the idea of only post-creation hook try to lose
this kind of benefit instead of half dozen of exceptions.

I think MVCC visibility is just an actualization of the matters.
The point is that we can be released from the task to consider
where is the right place for security hooks, as long as it will
be placed next to the existing DAC checks.
It seems to me its simplicity of design is unignorable benefit.

> And the point
> of this, apparently, is so that you can avoid using the standard
> syscache functions that the entire backend uses for retrieving
> information about objects and instead extract it in some other way;
> and/or avoid having to deal with the MVCC properties of which the rest
> of the backend must be aware.

It just means it is not impossible...
However, it requires the plugin modules need to know everything;
such as what is visible/invisible. It seems to me too closely-
coupled interface.

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