Re: is_superuser is not documented

From: Joseph Koshakow <koshy44(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: is_superuser is not documented
Date: 2023-06-07 17:33:03
Message-ID: CAAvxfHco7iGw4NarymhfLWN6PjzYRrbYFt2BnSFeSD5sFzqEJQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 7, 2023 at 11:36 AM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
wrote:
>
>
>
> On 2023/06/07 23:15, Joseph Koshakow wrote:
> > I think I may have discovered a reason why is_superuser is
> > intentionally undocumented. is_superuser is not updated if a role's
> > superuser attribute is changed by another session. Therefore,
> > is_superuser may show you an incorrect stale value.
> >
> > Perhaps this can be fixed with a show_hook? Otherwise it's probably
> > best not to document a GUC that can show an incorrect value.
>
> Or we can correct the description of is_superuser, for example,
> "True if the current role had superuser privileges when it connected to
> the database. Note that this parameter doesn't always indicate
> the current superuser status of the role."?

That description isn't exactly accurate either, since is_superuser is
re-evaluated whenever the role GUC is changed (i.e. through SET ROLE
or RESET ROLE), and potentially at other times I'm not aware of. I'm
curious to hear what others think though, since it seems like a bit of
a footgun. It will be up to the user to understand when `is_superuser`
is accurate or inaccurate. In most cases it will be impossible for
them to know unless they get the same information elsewhere, like
through pg_roles.

As an aside I think there's a similar issue with the
AuthenticatedUserIsSuperuser static variable. That variable is
initialized in miscinit.c in the InitializeSessionUserId function
based on whether the session role is a superuser when connecting. Then
as far as I can tell the variable is never updated.

When executing a SET SESSION AUTHORIZATION command, we check if
AuthenticatedUserIsSuperuser is true to determine if the session is
allowed to execute the command. That check happens in miscinit.c in the
SetSessionAuthorization function.

This means that if some role, r, connects as a superuser and then later
some other role removes r's superuser attribute, r can always set their
session authorization to a different role with the superuser attribute
to regain superuser privileges. So as long as r maintains an active
connection, they can never truly lose their superuser privileges.

- Joe Koshakow

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-06-07 17:37:45 Re: Do we want a hashset type?
Previous Message Tomas Vondra 2023-06-07 17:05:39 Re: memory leak in trigger handling (since PG12)