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

From: Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Nasby <jim(dot)nasby(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Things I don't like about \du's "Attributes" column
Date: 2024-01-28 19:51:14
Message-ID: 1c0e82ac-8fe8-429a-a5a5-11a76d5e57c2@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23.01.2024 04:18, Tom Lane 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.

I've been thinking about it. Therefore, the column "Password?" is shown
only for version 17 and older.

> Can you get the same result without changing pg_roles?

Hm. I'm not sure if this is possible.

> 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.

Yes, I remember your caution about security from the original post.
I'll try to explain why changing pg_roles is acceptable.
Now \du shows column "Valid until". We know that you can set
the password expiration date without having a password, but this is
more likely a mistake in role maintenance. In most cases, a non-null
value indicates that the password has been set. Therefore, security
should not suffer much, but it will help the administrator to see
incorrect values.

On 23.01.2024 05:22, David G. Johnston wrote:
> 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).

Good point.
But what about "Valid until". Can roles without superuser or createrole
attributes see it? The same about "Connection limit"?

I'll think about it and try to implement in the next patch version within a few days.
Thank you for review.

--
Pavel Luzanov
Postgres Professional:https://postgrespro.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2024-01-28 20:09:05 Re: Schema variables - new implementation for Postgres 15
Previous Message Pavel Stehule 2024-01-28 19:34:40 Re: Schema variables - new implementation for Postgres 15