Re: replacing role-level NOINHERIT with a grant-level option - Mailing list pgsql-hackers

From Pavel Luzanov
Subject Re: replacing role-level NOINHERIT with a grant-level option
Date
Msg-id 5de71739-c856-a9ea-588d-5254d1b8cf75@postgrespro.ru
Whole thread Raw
In response to Re: replacing role-level NOINHERIT with a grant-level option  (Robert Haas <robertmhaas@gmail.com>)
List 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




pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Suppressing useless wakeups in walreceiver
Next
From: David Rowley
Date:
Subject: Re: Have nodeSort.c use datum sorts single-value byref types