Re: Monitoring roles patch

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Monitoring roles patch
Дата
Msg-id 20170328184348.GI9812@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Monitoring roles patch  (Mark Dilger <hornschnorter@gmail.com>)
Список pgsql-hackers
Greetings,

* Mark Dilger (hornschnorter@gmail.com) wrote:
> After a bit of introspection, I think what is really bothering me is not the
> inability to revoke permissions, since as you say I can choose to not assign
> the role to anybody.  What bothers me is that this feature implicitly redefines
> what is meant by the keyword PUBLIC.  If I go around the database
> revoking privileges on everything from PUBLIC, I should end up with
> a database that is inaccessible to anyone but superuser, right?

While I accept your concern and confusion, this isn't accurate.
REVOKE'ing rights from PUBLIC only removes those rights GRANT'd to
PUBLIC, it doesn't remove rights which have been GRANT'd to other users.

In a degenerate system where the only roles which exist are the
superuser role and the pseudo-role 'public', you would be correct with
your statement above, but this patch doesn't change that because you
will not have GRANT'd the new role to anyone.

> All views,
> functions, tables, etc., would all be locked down.  But after this proposed
> change, IIUC, there would still be a bit of access available to this/these
> proposed non-superuser role(s) which have hardcoded permissions.

These non-superuser roles can't be logged into and if they are not
GRANT'd to anyone then it's essentially the same as if they don't exist.

> That's quite a significant change to the security model of the database,
> and I don't think it is something users would expect from the release notes
> if the release notes for this feature say something like:
>
>     "added database monitoring functionality"

Having more in the release notes and in the documentation is certainly
important, but this is not changing the security model of the database
in any significant way.

> To be fair, I have not tried to revoke everything from everybody on a
> database to verify that their aren't already problems of this sort.  Perhaps
> the cows have already left the barn.

Right, which means that, in addition to the points made above, this
isn't a use-case which is actually even all that interesting to
consider.

Thanks!

Stephen

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Protection lost in expression eval changeover
Следующее
От: Nikolay Shaplov
Дата:
Сообщение: Re: [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM