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-18 14:50:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2012/1/18 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Tue, Jan 17, 2012 at 10:55 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> Do I modify the patch to place object-access-hook on deleteOneObject
>> (probably, it is the best position to track actual deletion)?
>> One problem is case of deletion of columns by ALTER TABLE.
>> It just marks "attisdropped" flag; without removing catalog entry.
>> Do we ought to put this hook on ATExecDropColumn exceptionally?
> +1.
The attached one is a revised version.
It adds OAT_DROP on the following points:
* deleteOneObject()
* dropdb()
* DropTableSpace()
* DropRole()

One thing I overlooked on the upthread is that ATExecDropColumn()
also calls performDeletion, then RemoveAttributeById() set attisdropped.
So, this function was not a point to be hooked exceptionally.

On the other hand, as a source code comment on doDeletion() says,
deletion of shared database objects (database, tablespace and role)
are not hooked on deleteOneObject(), thus, I added a hook for each
deletion code of these objects.

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.

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Attachment: pgsql-v9.2-drop-permissions.v2.patch
Description: application/octet-stream (47.6 KB)

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2012-01-18 15:05:57
Subject: Re: gistVacuumUpdate
Previous:From: Jaime CasanovaDate: 2012-01-18 14:46:20
Subject: Re: Measuring relation free space

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