Re: security hook on table creation

2010/9/29 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> But with that exception,
>> they seemed to think that coarse-grained permissions would be fine for
>> a basic implementation: perhaps even just install something in
>> ProcessUtility_hook and bounce DDL across the board, so long as it's
>> controlled by reference to the security policy rather than by DAC.  I
>> think we can do better than that in a pretty short period of time if
>> we avoid getting side-tracked, but the key is that we have to avoid
>> getting side-tracked.
>>
> In this approach, we eventually need to deploy the hooks on object creation
> as we are currently working on. So, I don't think using ProcessUtility_hook
> for coarse-grained permissions is a right direction.

Well, it may be the easiest way to do certain things. For example, if
you wanted to control access to a command such as LOAD (which
presumably you do since otherwise a loadable module could trivially
subvert the security policy), it's unclear to me that there's any need
for a new hook; ProcessUtility_hook might very well be the best way to
tackle that. We need to consider the best way to handle each case.
In some cases, all of the necessary information may not be available
when ProcessUtility_hook is called, but where it is, we shouldn't
reinvent the wheel.

With respect to this patch, I think we are on the same page now, with
possibly some disagreement about how far it makes sense to go with
this that needn't concern us for the present. I'm going to mark this
patch Returned with Feedback, because we need to move on to other
patches that are closer to being committable.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company