On Mon, Jan 22, 2024 at 6:26 PM Tom Lane <t...@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.
