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

On Tue, Jan 10, 2012 at 7:51 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> The attached patch adds OAT_DROP object-access-hook around permission
> checks of object deletion.
> Due to the previous drop statement reworks, the number of places to
> put this hook is limited to these six points: RemoveObjects,
> RemoveRelations, ATExecDropColumn, dropdb, DropTableSpace and
> shdepDropOwned().
>
> In sepgsql side, it checks {drop} permission for each object types,
> and {remove_name} permission to the schema that owning the object
> being removed. I'm still considering whether the drop permission
> should be applied on objects being removed in cascade mode.
> It is not difficult to implement. We can determine the bahavior on
> object deletion with same manner of creation; that saves contextual
> information using ProcessUtility hook.
>
> At this moment, the current proposed patch does not apply checks on
> cascaded deletion, according to SQL behavior. However, my concern is
> that user can automatically have right to remove all the objects
> underlying a partidular schema being removable, even if individual
> tables or functions are not able to be removed.
>
> So, my preference is sepgsql references dependency tables to check
> {drop} permissions of involved objects, not only the target object.

Hmm. I kind of wonder if we shouldn't just have the OAT_DROP hook get
invoked for every actual drop, rather than only for the top-level
object. It's somewhat appealing to have the hook more-or-less match
up the permissions checks, as you have it here, but in general it
seems more useful to have a callback for each thing dropped than to
have a callback for each thing named to be dropped. What is your
opinion?

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