Skip site navigation (1) Skip section navigation (2)

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

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [v9.2] sepgsql's DROP Permission checks
Date: 2012-01-19 08:51:50
Message-ID: CADyhKSVLpEJJPsRz8Nwy26F1Bem3owZDDjyMfmbra6n=_wVJXg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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>

In response to

Responses

pgsql-hackers by date

Next:From: Gražvydas ValeikaDate: 2012-01-19 09:13:16
Subject: Re: Strange primary key constraint influence to grouping
Previous:From: Kevin GrittnerDate: 2012-01-19 04:29:57
Subject: Re: Strange primary key constraint influence to grouping

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group