Re: Can db user change own password?

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Toomas <toomas(dot)kristin(at)gmail(dot)com>
Cc: Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Can db user change own password?
Date: 2021-10-21 19:49:02
Message-ID: 5dcd835a-cb91-6c67-4156-ed2787190b33@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 10/21/21 10:51, Tom Lane wrote:
> Toomas <toomas(dot)kristin(at)gmail(dot)com> writes:
>> 2) db=> select current_user, session_user;
>> current_user | session_user
>> --------------+--------------
>> db_owner | db_user
>> (1 row)
>
> Given that setup, I wonder which role you expected \password to change.
>
> If we target the current_user, we can expect the command to succeed.
> I'm just wondering if people will find that surprising.
> Targeting the session_user might be less surprising (or not?)
> but as this example shows, it can fail.

Well from here:

https://www.postgresql.org/docs/current/sql-set-session-authorization.html

'The current user identifier is relevant for permission checking.'

To me current_user would be the less surprising choice.

>
> One thing that would help, regardless of which definition we think
> is most appropriate, is to have \password explicitly say which role
> it's intending to set the password for:
>
> db=> \password
> Enter new password for role "dbowner":
> Enter it again:

Yes, that would be helpful in untangling who you are actually pointing at.

>
> regards, tom lane
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2021-10-21 19:52:26 Re: Can db user change own password?
Previous Message Saurav Sarkar 2021-10-21 18:33:39 Re: Connection queuing by connection pooling libraries