Tom Lane wrote:
> KaiGai Kohei <kaigai@kaigai.gr.jp> writes:
>> However, I think we have a few issues, and it makes unclear whether
>> we can make an agreement in the community.
>> The one is a cost of security hooks. They consume a bit more CPU steps
>> when a security mechanism is enabled. The other is prevention to override
>> a few hooks (ExecutorRun_hook and planner_hook), because they assume
>> standard implementations to be executed.
>
> I think your chances of taking those hooks away are zero. It would
> cripple a lot of other facilities that people are more interested in
> than they are in SEPostgres. In any case, the only way to use those
> hooks is to load C code into the backend, and anyone who can do that
> already has the keys to the kingdom. I hope you are not suffering
> from any illusions about being able to defend against arbitrary add-on
> C code.
I removed the two hooks at the r1244 patch set.
As you said, it is fundamentally danger to load uncertain binary modules.
Thus, what we should do is checks on module loading.
The default security policy requires loadable modules to be labeled as
'lib_t' type which means shared library files installed correctly.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>