Re: Superowners

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
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-01-30 14:04:08
Message-ID: CANP8+jL3V3AkRQ04eGQs+LPiJ1U8H8vF2aeB+M6t-vWnaADDtg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30 January 2017 at 14:43, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> We need to make sure that we're actually talking about the same things
> here, because we've now shifted from ownership-like privileges to those
> privielges which can be GRANT'd, and the two are far from the same.

Agreed. Let me reiterate: all I want in this release is
super-ownership. Other stuff is way more complex and if it happens at
all it can happen in later release.

> Would these super-privileges be seen when doing a \dp on a table?

No, keep it simple, treat like ownership

> Are
> we going to record the super-privileges into every object which exists
> when the command is called and then also into new objects when they're
> created?

No. Super privs are implicit and do not need to be added to each new object.

> Or are we going to have an additional catalog lookup for every
> privilege check?

No, my vision is to replace the superuser() test with a
has_super_privs() check, so the cost is identical to existing
overhead.

I envisage a very small patch. I'll write it so we can see, not in
time for Brussels though.

>> * 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.
>
> We should at least consider if we really want upgrades to automatically
> set up these super-privileges or not.

This wouldn't be needed if the database owner has the super-privs automatically.

>> * This model is needed now, or at least change in this area will be
>> easier because of PG10.0
>
> This doesn't strike me as a terribly good argument. I'm sure we could
> do this for PG11 too.
>
>> 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.
>
> For my 2c, at least, that makes it sound like a very good project for a
> student to work on. That said, I'm not against doing it now, if someone
> wants to spend the time to do so.
>
>> 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.
>
> I don't believe doing something quick now will lead us to a place where
> we will easily be able to make it more flexible later. I'm much more
> concerned that we'll end up painting ourselves into a corner that's
> difficult to get out of as privileges are, generally speaking, not
> something we can really whack around from release to release. They're
> extremely user-visible and any issues will almost certainly lead to
> security releases.

Which is why we should keep it simple, which is why/what I originally proposed.

--
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 Bernd Helmle 2017-01-30 14:26:20 Re: Deadlock in XLogInsert at AIX
Previous Message Heikki Linnakangas 2017-01-30 13:52:59 Re: Potential data loss of 2PC files