Re: [v9.2] sepgsql's DROP Permission checks - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: [v9.2] sepgsql's DROP Permission checks
Date
Msg-id CADyhKSWR1agHnNvYQD9X_e8RPUpLO2JC7yWx3gqUgszi=d=TVQ@mail.gmail.com
Whole thread Raw
In response to Re: [v9.2] sepgsql's DROP Permission checks  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [v9.2] sepgsql's DROP Permission checks  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
2012/1/18 Robert Haas <robertmhaas@gmail.com>:
> On Tue, Jan 17, 2012 at 10:55 AM, Kohei KaiGai <kaigai@kaigai.gr.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.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

Attachment

pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: Measuring relation free space
Next
From: Heikki Linnakangas
Date:
Subject: Re: gistVacuumUpdate