On Wed, Jun 7, 2023 at 11:36 AM Fujii Masao <masao.fu...@oss.nttdata.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