Re: security hook on table creation

(2010/10/07 6:21), Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
>> 2010/10/5 KaiGai Kohei<kaigai@ak.jp.nec.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.
> 
Performance optimization is not the point here.

If we need to call CommandCounterIncrement() before invocation of security
hooks, we also need to analyze its side-effect and to confirm it is harmless.
Even if it is harmless, I think it gives us more burden of code maintenance
than the idea of two hooks on creation.

>> Maybe we need a variant of InvokeObjectAccessHook that does a CCI only
>> if a hook is present.
> 
> The problem I see with this idea is that it becomes a lot harder to
> track down whether it ocurred or not for any given operation.
> 
Yes, it is a burden of code maintenance.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>