On 17.08.2023 05:36, Bruce Momjian wrote:
On Wed, Aug 9, 2023 at 08:35:21PM -0400, Bruce Momjian wrote:
On Sat, Aug 5, 2023 at 04:08:47PM -0700, Noah Misch wrote:
Author: Robert Haas <rh...@postgresql.org>
2022-08-25 [e3ce2de09] Allow grant-level control of role inheritance behavior.
-->
<listitem>
<para>
Allow GRANT to control role inheritance behavior (Robert Haas)
</para>
<para>
By default, role inheritance is controlled by the inheritance status of the
member role. The new GRANT clauses WITH INHERIT and WITH ADMIN can now
override this.
</para>
</listitem>
<!--
Author: Robert Haas <rh...@postgresql.org>
2023-01-10 [e5b8a4c09] Add new GUC createrole_self_grant.
Author: Daniel Gustafsson <dgustafs...@postgresql.org>
2023-02-22 [e00bc6c92] doc: Add default value of createrole_self_grant
-->
<listitem>
<para>
Allow roles that create other roles to automatically inherit the new role's
rights or SET ROLE to the new role (Robert Haas, Shi Yu)
</para>
<para>
This is controlled by server variable createrole_self_grant.
</para>
</listitem>
Similarly, v16 radically changes the CREATE ROLE ... WITH INHERIT clause. The
clause used to "change the behavior of already-existing grants." Let's merge
these two and move the combination to the incompatibilities section.
I need help with this. I don't understand how they can be combined, and
I don't understand the incompatibility text in commit e3ce2de09d:
If a GRANT does not specify WITH INHERIT, the behavior based on
whether the member role is marked INHERIT or NOINHERIT. This means
that if all roles are marked INHERIT or NOINHERIT before any role
grants are performed, the behavior is identical to what we had before;
otherwise, it's different, because ALTER ROLE [NO]INHERIT now only
changes the default behavior of future grants, and has no effect on
existing ones.
I am waiting for an answer to this question, or can I assume the release
notes are acceptable?
I can try to explain how I understand it myself.
In v15 and early, inheritance of granted to role privileges depends on
INHERIT attribute of a role:
create user alice;
grant pg_read_all_settings to alice;
By default privileges inherited:
\c - alice
show data_directory;
data_directory
-----------------------------
/var/lib/postgresql/15/main
(1 row)
After disabling the INHERIT attribute, privileges are not inherited:
\c - postgres
alter role alice noinherit;
\c - alice
show data_directory;
ERROR: must be superuser or have privileges of pg_read_all_settings to
examine "data_directory"
In v16 changing INHERIT attribute on alice role doesn't change
inheritance behavior of already granted roles.
If we repeat the example, Alice still inherits pg_read_all_settings
privileges after disabling the INHERIT attribute for the role.
Information for making decisions about role inheritance has been moved
from the role attribute to GRANT role TO role [WITH INHERIT|NOINHERIT]
command and can be viewed by the new \drg command:
\drg
List of role grants
Role name | Member of | Options | Grantor
-----------+----------------------+--------------+----------
alice | pg_read_all_settings | INHERIT, SET | postgres
(1 row)
Changing the INHERIT attribute for a role now will affect (as the
default value) only future GRANT commands without an INHERIT clause.
--
Pavel Luzanov
Postgres Professional: https://postgrespro.com
