Re: replacing role-level NOINHERIT with a grant-level option

From: Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replacing role-level NOINHERIT with a grant-level option
Date: 2022-10-26 09:51:50
Message-ID: 5de71739-c856-a9ea-588d-5254d1b8cf75@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-10-26 10:35:37 Re: Have nodeSort.c use datum sorts single-value byref types
Previous Message Bharath Rupireddy 2022-10-26 09:35:20 Re: Suppressing useless wakeups in walreceiver