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

[v9.2] sepgsql's DROP Permission checks

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: PgHacker <pgsql-hackers(at)postgresql(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: [v9.2] sepgsql's DROP Permission checks
Date: 2012-01-10 12:51:23
Message-ID: CADyhKSVF-8y_tEZnG3naJ09ajiT+69p9EvmpANTNc1fQRdzGvw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Thanks,
-- 
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

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

Responses

pgsql-hackers by date

Next:From: Joachim WielandDate: 2012-01-10 12:56:36
Subject: Re: Sending notifications from the master to the standby
Previous:From: Kohei KaiGaiDate: 2012-01-10 11:28:14
Subject: [v9.2] Add GUC sepgsql.client_label

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