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 по дате отправления:

Предыдущее
От: Junwang Zhao
Дата:
Сообщение: Re: make dist using git archive
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Things I don't like about \du's "Attributes" column