Re: [v9.2] sepgsql's DROP Permission checks

2012/1/18 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Tue, Jan 17, 2012 at 10:55 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> Do I modify the patch to place object-access-hook on deleteOneObject
>> (probably, it is the best position to track actual deletion)?
>> One problem is case of deletion of columns by ALTER TABLE.
>> It just marks "attisdropped" flag; without removing catalog entry.
>> Do we ought to put this hook on ATExecDropColumn exceptionally?
>
> +1.
>
The attached one is a revised version.
It adds OAT_DROP on the following points:
* deleteOneObject()
* dropdb()
* DropTableSpace()
* DropRole()

One thing I overlooked on the upthread is that ATExecDropColumn()
also calls performDeletion, then RemoveAttributeById() set attisdropped.
So, this function was not a point to be hooked exceptionally.

On the other hand, as a source code comment on doDeletion() says,
deletion of shared database objects (database, tablespace and role)
are not hooked on deleteOneObject(), thus, I added a hook for each
deletion code of these objects.

In sepgsql side, it determines a case to apply permission checks
according to the contextual information; that is same technique
when we implemented create permission.
Thus, it could checks db_xxx:{drop} permission correctly.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>