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-30 10:33:50
Message-ID: CANP8+j+fmuEiuz-ut2y8wVObXCVQY19QN1p18G-PwHzE-w=ueQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 January 2017 at 22:48, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 1/26/17 1:25 PM, Simon Riggs wrote:
>> 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.
>
> This basically sounds like a GRANT $privilege ON ALL $objecttype TO
> $user. So you could have a user that can read everything, for example.
>
> This kind of thing has been asked for many times, but that quieted down
> when the default privileges feature appeared. I think it would still be
> useful.

I would call these "super privileges".

Peter suggests that we have a much more flexible structure for super-privileges.

In Peter's model, Tom's suggestion woud be to grant all of these
automatically to database owners.
GRANT ALL ON ALL TABLES TO $user
GRANT ALL ON ALL SEQUENCES TO $user
GRANT ALL ON ALL FUNCTIONS TO $user

Either of them would be good for me, as long as we implement the rule
as Tom suggests that this would never apply to objects owned by a
superuser.

After thinking about this, the things I care about are

* That super-privileges can be executed efficiently at run-time. If
they cause major overheads, especially in cases where they have not
been granted then we would have a big problem.

* Some super-privileges should exist by default. If super-privileges
exist only when granted by superusers and we have no access to
superusers then they never will exist, so they will be mostly useless
in many cases.

* This model is needed now, or at least change in this area will be
easier because of PG10.0

Neither of those things make me think deferring this and allowing a
student to work on it in the future would be a useful outcome. The
task looks to be a small amount of dev, a medium amount of design and
a lot of checking and documentation.

So my proposal is to implement what Tom suggests now, which I will now
describe as automatic super-privileges for database owning roles. And
we can implement a more flexible scheme for explicit GRANTs to other
roles in later releases.

--
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 Vladimir Rusinov 2017-01-30 11:01:29 Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal
Previous Message Amit Kapila 2017-01-30 10:32:22 Re: Supporting huge pages on Windows