2012/1/19 Robert Haas <robertmh...@gmail.com>:
> On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai <kai...@kaigai.gr.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 <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
