Re: [HACKERS] Superowners - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [HACKERS] Superowners
Date
Msg-id CANP8+jK13M26g+zOvoHDG5V1Ua09N6zKZU062cVVqry_-8pZ9g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Superowners  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Superowners  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On 26 January 2017 at 17:37, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 1/24/17 8:19 AM, Tom Lane wrote:
>> What about just saying that the database owner has those privileges?
>> After all, the ultimate privilege of an owner is to drop the object
>> (and then remake it as she pleases), and the DB owner has that option
>> w.r.t. the whole database.  So I'm not sure we need to invent a new
>> concept.
>
> A database owner does not necessarily have the permission to create a
> new database.

So the concept I was looking for is already there: on pg_database the
database owner is referred to as the DBA.

I'd like to be able to give permision to someone to control all
user-owned objects in the database, yet not be allowed to do anything
that touches filesystem or creates potentially unsafe functions.

This allows a separation of duty between people that run a service and
people that use it.

That should include the ability to dump all objects, yet without any
security details. And it should allow someone to setup logical
replication easily, including both trigger based and new logical
replication. And GRANT ON ALL should work.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscription
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal