This commit adds some notes about the inability to remove superuser
privileges from the bootstrap superuser. This has been blocked
since commit
e530be2c5c , but it wasn't intended be a supported
feature before that, either.
In passing, change "bootstrap user" to "bootstrap superuser" in a
couple places.
Author: Yurii Rashkovskii
Reviewed-by: Vignesh C, David G. Johnston
Discussion: https://postgr.es/m/CA%2BRLCQzSx_eTC2Fch0EzeNHD3zFUcPvBYOoB%2BpPScFLch1DEQw%40mail.gmail.com
This role also behaves as a normal
- database superuser .
+ database superuser ,
+ and its superuser status cannot be removed.
GRANT and
REVOKE for that.)
Attributes not mentioned in the command retain their previous settings.
- Database superusers can change any of these settings for any role.
+ Database superusers can change any of these settings for any role, except
+ for changing the SUPERUSER property for the
+ bootstrap superuser .
Non-superuser roles having CREATEROLE privilege can
change most of these properties, but only for non-superuser and
non-replication roles for which they have been granted
options. Thus, the fact that privileges are not inherited by default nor
is SET ROLE granted by default is a safeguard against
accidents, not a security feature. Also note that, because this automatic
- grant is granted by the bootstrap user, it cannot be removed or changed by
+ grant is granted by the bootstrap super user, it cannot be removed or changed by
the CREATEROLE user; however, any superuser could
revoke it, modify it, and/or issue additional such grants to other
CREATEROLE users. Whichever CREATEROLE
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("permission denied to alter role"),
- errdetail("The bootstrap user must have the %s attribute.",
+ errdetail("The bootstrap super user must have the %s attribute.",
"SUPERUSER")));
new_record[Anum_pg_authid_rolsuper - 1] = BoolGetDatum(should_be_super);