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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [v9.2] sepgsql's DROP Permission checks
Date: 2012-01-17 02:11:46
Message-ID: CA+TgmoYr=t5rvmtCnhNtY7F-XQ-2+NYCdkAaFDMn-5hRETzm5g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-01-17 02:18:56
Subject: Re: Should we add crc32 in libpgport?
Previous:From: Josh BerkusDate: 2012-01-17 02:02:57
Subject: Re: Checkpoint sync pause

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