Re: Superowners

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Superowners
Date: 2017-01-26 18:25:01
Message-ID: CANP8+jK13M26g+zOvoHDG5V1Ua09N6zKZU062cVVqry_-8pZ9g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26 January 2017 at 17:37, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-01-26 18:26:10 Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal
Previous Message Robert Haas 2017-01-26 18:21:44 Re: [PATCH] Generic type subscription