Re: security hook on table creation

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.

Thanks,

(2010/10/08 9:39), KaiGai Kohei wrote:
> (2010/10/08 0:21), Robert Haas wrote:
>> On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)com> wrote:
>>> Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
>>>> 2010/10/5 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>
>>>>> However, we also have a few headache cases.
>>>>> DefineType() creates a new type object and its array type, but it does not
>>>>> call CommandCounterIncrement() by the end of this function, so the new type
>>>>> entries are not visible from the plugin modules, even if we put a security
>>>>> hook at tail of the DefineType().
>>>>> DefineFunction() also has same matter. It create a new procedure object,
>>>>> but it also does not call CommandCounterIncrement() by the end of this
>>>>> function, except for the case when ProcedureCreate() invokes language
>>>>> validator function.
>>>>
>>>> So I guess the first question here is why it's important to be able to
>>>> see the new entry. I am thinking that you want it so that, for
>>>> example, you can fetch the namespace OID to perform an SE-Linux type
>>>> transition. Is that right?
>>>
>>> I'm not sure that there's any point trying to optimize these to the
>>> point of avoiding CommandCounterIncrement. Surely DefineType et al are
>>> not performance-sensitive operations.
>>
>> OK, fair enough. Let's just do it unconditionally then.
>>
> I guess we will need to have such kind of discussion whenever we touch
> the code around security hooks in the future, if hooks would not be put
> next to the existing DAC checks.
> Although we need to define several hooks on object creation in addition
> to the main hook, separating it into two parts helps us to understand
> and maintenance.
>
> | In the case when we have two hooks, obviously, the prep-creation
> | hook will be after the DAC checks, and the post-creation hook will
> | be after the insert/update of system catalogs.
>
> I still don't think such a simple principle overs our capability, and
> also don't think it is more complex than matters around the idea of
> only post-creation hooks, such as CommandCounterIncrement().
>
> Thanks,

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