Re: replacing role-level NOINHERIT with a grant-level option
Pavel Luzanov <p.luzanov@postgrespro.ru>
From: Pavel Luzanov <p.luzanov@postgrespro.ru>
To: Robert Haas <robertmhaas@gmail.com>,
Nathan Bossart <nathandbossart@gmail.com>
Cc: tushar <tushar.ahuja@enterprisedb.com>, Joe Conway <mail@joeconway.com>,
Tom Lane <tgl@sss.pgh.pa.us>, "Bossart, Nathan" <bossartn@amazon.com>,
Stephen Frost <sfrost@snowman.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-10-26T09:51:50Z
Lists: pgsql-hackers
Hello,
> Thanks for reviewing. Committed.
Let me return to this topic.
After looking at the changes in this patch, I have a suggestion.
The inheritance option for role memberships is important information to
know if the role privileges will be available automatically or if a
switch with a SET ROLE command is required. However, this information
cannot be obtained with psql commands, specifically \du or \dg.
Previously, you could see the inherit attribute of the role (its absence
is shown with \du). Now you have to look in the pg_auth_members system
catalog.
My suggestion is to add information about pg_auth_members.inherit_option
to the output of \du (\dg).
If so, we can also add information about pg_auth_members.admin_option.
Right now this information is not available in psql command output either.
I thought about how exactly to represent these options in the output
\du, but did not find a single solution. Considered the following choices:
1.
Add \du+ command and for each membership in the role add values of two
options. I haven't done a patch yet, but you can imagine the changes
like this:
CREATE ROLE alice LOGIN IN ROLE pg_read_all_data;
\du+ alice
List of roles
Role name | Attributes | Member of
-----------+------------+--------------------
alice | | {pg_read_all_data(admin=f inherit=t)}
It looks long, but for \du+ it's not a problem.
2.
I assume that the default values for these options will rarely change.
In that case, we can do without \du+ and output only the changed values
directly in the \du command.
GRANT pg_read_all_data TO alice WITH INHERIT FALSE;
2a.
\du alice
List of roles
Role name | Attributes | Member of
-----------+------------+--------------------
alice | | {pg_read_all_data(inherit=f)}
2b.
Similar to GRANT OPTION, we can use symbols instead of long text
(inherit=f) for options. For example, for the ADMIN OPTION we can use
"*" (again similar to GRANT OPTION), and for the missing INHERIT option
something else, such as "-":
GRANT pg_read_all_data TO alice WITH ADMIN TRUE;
GRANT pg_write_all_data TO alice WITH INHERIT FALSE;
\du alice
List of roles
Role name | Attributes | Member of
-----------+------------+--------------------
alice | | {pg_read_all_data*-,pg_write_all_data-}
But I think choices 2a and 2b are too complicated to understand.
Especially because the two options have different default values. And
even more. The default value for the INHERIT option depends on the value
of the INHERIT attribute for the role.
So I like the first choice with \du+ better.
But perhaps there are other choices as well.
If it's interesting, I'm ready to open a new thread (the commitfest
entry for this topic is now closed) and prepare a patch.
--
Pavel Luzanov
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix a bug in roles_is_member_of.
- 0101f770a05b 16.0 landed
-
docs: Fix up some out-of-date references to INHERIT/NOINHERIT.
- 620ac285483f 16.0 landed
-
Allow grant-level control of role inheritance behavior.
- e3ce2de09d81 16.0 landed
-
Make role grant system more consistent with other privileges.
- ce6b672e4455 16.0 cited
-
Document basebackup_to_shell.required_role.
- 26a0c025e233 15.0 landed