Re: [HACKERS] Superowners

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [HACKERS] Superowners
Дата
Msg-id 20170130151535.GD9812@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [HACKERS] Superowners  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Simon,

* Simon Riggs (simon@2ndquadrant.com) wrote:
> 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.

Alright.

> > Would these super-privileges be seen when doing a \dp on a table?
>
> No, keep it simple, treat like ownership

Well, we do list ownership in \d.

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

Alright, that then involves addiitonal checks happening run-time.  I'm
not against that, simply pointing it out.

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

It's unclear to me why you're suggesting the cost would be identical.
We check superuser() first and any change to that check to do something
additional (like, look up who the database owner is) would mean an
increase in overhead.

I'm not saying that such overhead would be an issue, to be clear, but
it would be there.

That would also be a change from how ownership is done today- in
particular, superusers simply *bypass* checks, owners do *not*.  Users
are able to REVOKE the default rights that the owner has.  Of course,
the owner can GRANT those back, but it's still not the same as
superuser.

How is role membership going to be handled with this change also?  And
what about the information_schema?  Surely we will need to report the
privileges of these "super-owners" through those views, just as we do
for owners today.

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

While that would certainly be nice, it doesn't seem very likely to work
out that way, unfortunately.

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

If the database owner is now a 'super owner' automatically then we
certainly do need to consider that we're changing the privilege system
for everyone as soon as they start using PG10.  I'm not saying that it's
necessairly an issue, to be clear, and I believe Tom's argument is a
good one, but I do think we need to be sure we consider such a change
carefully.

Thanks!

Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] One-shot expanded output in psql using \G
Следующее
От: Christoph Berg
Дата:
Сообщение: Re: [HACKERS] One-shot expanded output in psql using \G