On Tue, Jan 10, 2012 at 7:51 AM, Kohei KaiGai <kai...@kaigai.gr.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
