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

2012/1/19 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> 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.
>
> Why do we need the contextual information in this case?  Why
> can't/shouldn't the decision be made solely on the basis of what
> object is targeted?
>
Several code-paths to remove a particular objects are not appropriate
to apply permission checks. For example...

[1] Cleanup of temporary objects
on_shmem_eixt() registers RemoveTempRelationsCallback(), then
it eventually calls deleteWhatDependsOn() that have an invocation
of deleteOneObject().
This code path is just an internal cleanup process, not related to
permission of the client.

[2] Cleanup of transient table at VACUUM FULL/CLUSTER command
rebuild_relation() creates a temporary table with make_new_heap(),
then it copies the contents of original table according to the order of
index, and calls finish_heap_swap() that swaps relation files and
removes the temporary table using performDeletion().
This code actually create and drop a table, however, it is quite
internal design and not related to permission of the client.

So, I think sepgsql should only applied to permission checks
object deletion invoked by user's operations, such as DropStmt.

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