Re: Preventing non-superusers from altering session authorization - Mailing list pgsql-hackers

From Joseph Koshakow
Subject Re: Preventing non-superusers from altering session authorization
Date
Msg-id CAAvxfHdj5H88W99anUoFf4OaH+Oozs=e7kF1mhsegxpWOsvQFQ@mail.gmail.com
Whole thread Raw
In response to Re: Preventing non-superusers from altering session authorization  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Preventing non-superusers from altering session authorization
Re: Preventing non-superusers from altering session authorization
List pgsql-hackers


On Wed, Jun 21, 2023 at 11:48 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
>    On Wed, Jun 21, 2023 at 04:28:43PM -0400, Joseph Koshakow wrote:
>    > +     roleTup = SearchSysCache1(AUTHOID, ObjectIdGetDatum(AuthenticatedUserId));
>    > +     if (!HeapTupleIsValid(roleTup))
>    > +             ereport(FATAL,
>    > +                             (errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
>    > +                                             errmsg("role with OID %u does not exist", AuthenticatedUserId)));
>    > +     rform = (Form_pg_authid) GETSTRUCT(roleTup);
>
>    I think "superuser_arg(AuthenticatedUserId)" would work here.

Yep, that worked. I've attached a patch with this change.

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

Thanks,
Joe Koshakow
Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Do we want a hashset type?
Next
From: Nathan Bossart
Date:
Subject: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX