Re: Superowners

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Superowners
Date: 2017-02-03 23:54:33
Message-ID: CA+TgmoYW=NgO7FQ=pSGY9rNjkRdiwJ0m=g9vYCF2N7U-dE8=HQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 30, 2017 at 5:33 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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.

I like Peter's model better, or more precisely Stephen's suggestion of
doing this via some default roles. Tom's model breaks backward
compatibility in a security-sensitive way, and it doesn't generalize
to things like wanting a user who can read everything but who has no
elevated write privileges. The idea of having predefined roles called
pg_read_anything, pg_write_anything, etc. seems quite elegant and very
powerful, and nobody's existing permissions structure has to change
unless they so desire.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-02-04 00:03:05 Re: multivariate statistics (v19)
Previous Message Robert Haas 2017-02-03 23:49:20 Re: Declarative partitioning - another take