Re: Preventing non-superusers from altering session authorization
От | Joseph Koshakow |
---|---|
Тема | Re: Preventing non-superusers from altering session authorization |
Дата | |
Msg-id | CAAvxfHfSbyHp62bqtovsEKu4M3oCQ-mehfq0OJ7Fk3OqkLwXtw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Preventing non-superusers from altering session authorization (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: Preventing non-superusers from altering session authorization
|
Список | pgsql-hackers |
>> That might be a good change? If the original authenticated role ID no
>> longer exists then we may want to return an error when trying to set
>> your session authorization to that role.
>
> I was curious why we don't block DROP ROLE if there are active sessions for
> the role or terminate any such sessions as part of the command, and I found
> this discussion from 2016:
>
> https://postgr.es/m/flat/56E87CD8.60007%40ohmu.fi
Ah, that makes sense that we don't prevent DROP ROLE on active roles.
Though, we do error when you try and set your role or session
authorization to a dropped role. So erroring on RESET SESSION
AUTHORIZATION when the original role is dropped makes it consistent
with SET SESSION AUTHORIZATION TO <dropped-original-role>. On the other
hand it makes it inconsistent with RESET ROLE, which does not error on
a dropped role.
- Joe Koshakow
>> longer exists then we may want to return an error when trying to set
>> your session authorization to that role.
>
> I was curious why we don't block DROP ROLE if there are active sessions for
> the role or terminate any such sessions as part of the command, and I found
> this discussion from 2016:
>
> https://postgr.es/m/flat/56E87CD8.60007%40ohmu.fi
Ah, that makes sense that we don't prevent DROP ROLE on active roles.
Though, we do error when you try and set your role or session
authorization to a dropped role. So erroring on RESET SESSION
AUTHORIZATION when the original role is dropped makes it consistent
with SET SESSION AUTHORIZATION TO <dropped-original-role>. On the other
hand it makes it inconsistent with RESET ROLE, which does not error on
a dropped role.
- Joe Koshakow
On Fri, Jun 23, 2023 at 1:54 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
On Thu, Jun 22, 2023 at 06:39:45PM -0400, Joseph Koshakow wrote:
> On Wed, Jun 21, 2023 at 11:48 PM Nathan Bossart <nathandbossart@gmail.com>
> wrote:
>> I see that RESET SESSION AUTHORIZATION
>> with a concurrently dropped role will FATAL with your patch but succeed
>> without it, which could be part of the reason.
>
> That might be a good change? If the original authenticated role ID no
> longer exists then we may want to return an error when trying to set
> your session authorization to that role.
I was curious why we don't block DROP ROLE if there are active sessions for
the role or terminate any such sessions as part of the command, and I found
this discussion from 2016:
https://postgr.es/m/flat/56E87CD8.60007%40ohmu.fi
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: