Re: Things I don't like about \du's "Attributes" column
| От | David G. Johnston |
|---|---|
| Тема | Re: Things I don't like about \du's "Attributes" column |
| Дата | |
| Msg-id | CAKFQuwZSFNKva0mhO2yQn8LQNyJiD2k2vR3rEV03SZ5e_DoUng@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Things I don't like about \du's "Attributes" column (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Mon, Jan 22, 2024 at 6:26 PM Tom Lane <tgl@sss.pgh.pa.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.
В списке pgsql-hackers по дате отправления: