Re: Things I don't like about \du's "Attributes" column

On Mon, Jan 22, 2024 at 6:26 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I wrote:
> > I think expecting the pg_roles view to change for this is problematic.
> > You can't have that in the back branches, so with this patch psql
> > will show something different against a pre-17 server than later
> > versions. At best, that's going to be confusing.
>
> Actually, even more to the point: while this doesn't expose the
> contents of a role's password, it does expose whether the role
> *has* a password to every user in the installation. I doubt
> that that's okay from a security standpoint. It'd need debate
> at the least.
>
>
Makes sense, more reason to put it within its own patch. At present it
seems like a createrole permissioned user is unable to determine whether a
given role has a password or not even in the case when that role would be
allowed to alter a role they've created to set or remove said password.
Keeping with the changes made in v16 it does seem worthwhile modifying
pg_roles to be sensitive to the role querying the view having both
createrole and admin membership on the role being displayed. With now
three possible outcomes: NULL if no password is in use, ********* if a
password is in use and the user has the ability to alter role, or
<insufficient privileges> (alt. N/A).

David J.