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

On 30 January 2017 at 14:43, Stephen Frost <sfrost@snowman.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