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