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
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 |