2022-01-24 15:25:27 -05:00
|
|
|
-- ok, superuser can create users with any set of privileges
|
|
|
|
|
CREATE ROLE regress_role_super SUPERUSER;
|
|
|
|
|
CREATE ROLE regress_role_admin CREATEDB CREATEROLE REPLICATION BYPASSRLS;
|
2023-01-10 12:44:49 -05:00
|
|
|
GRANT CREATE ON DATABASE regression TO regress_role_admin WITH GRANT OPTION;
|
Adjust interaction of CREATEROLE with role properties.
Previously, a CREATEROLE user without SUPERUSER could not alter
REPLICATION users in any way, and could not set the BYPASSRLS
attribute. However, they could manipulate the CREATEDB property
even if they themselves did not possess it.
With this change, a CREATEROLE user without SUPERUSER can set or
clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new
role or a role that they have rights to manage if and only if
that property is set for their own role.
This implements the standard idea that you can't give permissions
you don't have (but you can give the ones you do have). We might
in the future want to provide more powerful ways to constrain
what a CREATEROLE user can do - for example, to limit whether
CONNECTION LIMIT can be set or the values to which it can be set -
but that is left as future work.
Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha
Sharma.
Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 10:57:09 -05:00
|
|
|
CREATE ROLE regress_role_limited_admin CREATEROLE;
|
Restrict the privileges of CREATEROLE users.
Previously, CREATEROLE users were permitted to make nearly arbitrary
changes to roles that they didn't create, with certain exceptions,
particularly superuser roles. Instead, allow CREATEROLE users to make such
changes to roles for which they possess ADMIN OPTION, and to
grant membership only in roles for which they possess ADMIN OPTION.
When a CREATEROLE user who is not a superuser creates a role, grant
ADMIN OPTION on the newly-created role to the creator, so that they
can administer roles they create or for which they have been given
privileges.
With these changes, CREATEROLE users still have very significant
powers that unprivileged users do not receive: they can alter, rename,
drop, comment on, change the password for, and change security labels
on roles. However, they can now do these things only for roles for
which they possess appropriate privileges, rather than all
non-superuser roles; moreover, they cannot grant a role such as
pg_execute_server_program unless they themselves possess it.
Patch by me, reviewed by Mark Dilger.
Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com
2023-01-10 12:44:30 -05:00
|
|
|
CREATE ROLE regress_role_normal;
|
2022-01-24 15:25:27 -05:00
|
|
|
|
Adjust interaction of CREATEROLE with role properties.
Previously, a CREATEROLE user without SUPERUSER could not alter
REPLICATION users in any way, and could not set the BYPASSRLS
attribute. However, they could manipulate the CREATEDB property
even if they themselves did not possess it.
With this change, a CREATEROLE user without SUPERUSER can set or
clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new
role or a role that they have rights to manage if and only if
that property is set for their own role.
This implements the standard idea that you can't give permissions
you don't have (but you can give the ones you do have). We might
in the future want to provide more powerful ways to constrain
what a CREATEROLE user can do - for example, to limit whether
CONNECTION LIMIT can be set or the values to which it can be set -
but that is left as future work.
Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha
Sharma.
Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 10:57:09 -05:00
|
|
|
-- fail, CREATEROLE user can't give away role attributes without having them
|
|
|
|
|
SET SESSION AUTHORIZATION regress_role_limited_admin;
|
2022-01-24 15:25:27 -05:00
|
|
|
CREATE ROLE regress_nosuch_superuser SUPERUSER;
|
|
|
|
|
CREATE ROLE regress_nosuch_replication_bypassrls REPLICATION BYPASSRLS;
|
|
|
|
|
CREATE ROLE regress_nosuch_replication REPLICATION;
|
|
|
|
|
CREATE ROLE regress_nosuch_bypassrls BYPASSRLS;
|
Adjust interaction of CREATEROLE with role properties.
Previously, a CREATEROLE user without SUPERUSER could not alter
REPLICATION users in any way, and could not set the BYPASSRLS
attribute. However, they could manipulate the CREATEDB property
even if they themselves did not possess it.
With this change, a CREATEROLE user without SUPERUSER can set or
clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new
role or a role that they have rights to manage if and only if
that property is set for their own role.
This implements the standard idea that you can't give permissions
you don't have (but you can give the ones you do have). We might
in the future want to provide more powerful ways to constrain
what a CREATEROLE user can do - for example, to limit whether
CONNECTION LIMIT can be set or the values to which it can be set -
but that is left as future work.
Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha
Sharma.
Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 10:57:09 -05:00
|
|
|
CREATE ROLE regress_nosuch_createdb CREATEDB;
|
2022-01-24 15:25:27 -05:00
|
|
|
|
Adjust interaction of CREATEROLE with role properties.
Previously, a CREATEROLE user without SUPERUSER could not alter
REPLICATION users in any way, and could not set the BYPASSRLS
attribute. However, they could manipulate the CREATEDB property
even if they themselves did not possess it.
With this change, a CREATEROLE user without SUPERUSER can set or
clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new
role or a role that they have rights to manage if and only if
that property is set for their own role.
This implements the standard idea that you can't give permissions
you don't have (but you can give the ones you do have). We might
in the future want to provide more powerful ways to constrain
what a CREATEROLE user can do - for example, to limit whether
CONNECTION LIMIT can be set or the values to which it can be set -
but that is left as future work.
Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha
Sharma.
Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 10:57:09 -05:00
|
|
|
-- ok, can create a role without any special attributes
|
|
|
|
|
CREATE ROLE regress_role_limited;
|
|
|
|
|
|
|
|
|
|
-- fail, can't give it in any of the restricted attributes
|
|
|
|
|
ALTER ROLE regress_role_limited SUPERUSER;
|
|
|
|
|
ALTER ROLE regress_role_limited REPLICATION;
|
|
|
|
|
ALTER ROLE regress_role_limited CREATEDB;
|
|
|
|
|
ALTER ROLE regress_role_limited BYPASSRLS;
|
|
|
|
|
DROP ROLE regress_role_limited;
|
|
|
|
|
|
|
|
|
|
-- ok, can give away these role attributes if you have them
|
|
|
|
|
SET SESSION AUTHORIZATION regress_role_admin;
|
|
|
|
|
CREATE ROLE regress_replication_bypassrls REPLICATION BYPASSRLS;
|
|
|
|
|
CREATE ROLE regress_replication REPLICATION;
|
|
|
|
|
CREATE ROLE regress_bypassrls BYPASSRLS;
|
2022-01-24 15:25:27 -05:00
|
|
|
CREATE ROLE regress_createdb CREATEDB;
|
Adjust interaction of CREATEROLE with role properties.
Previously, a CREATEROLE user without SUPERUSER could not alter
REPLICATION users in any way, and could not set the BYPASSRLS
attribute. However, they could manipulate the CREATEDB property
even if they themselves did not possess it.
With this change, a CREATEROLE user without SUPERUSER can set or
clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new
role or a role that they have rights to manage if and only if
that property is set for their own role.
This implements the standard idea that you can't give permissions
you don't have (but you can give the ones you do have). We might
in the future want to provide more powerful ways to constrain
what a CREATEROLE user can do - for example, to limit whether
CONNECTION LIMIT can be set or the values to which it can be set -
but that is left as future work.
Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha
Sharma.
Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 10:57:09 -05:00
|
|
|
|
|
|
|
|
-- ok, can toggle these role attributes off and on if you have them
|
|
|
|
|
ALTER ROLE regress_replication NOREPLICATION;
|
|
|
|
|
ALTER ROLE regress_replication REPLICATION;
|
|
|
|
|
ALTER ROLE regress_bypassrls NOBYPASSRLS;
|
|
|
|
|
ALTER ROLE regress_bypassrls BYPASSRLS;
|
|
|
|
|
ALTER ROLE regress_createdb NOCREATEDB;
|
|
|
|
|
ALTER ROLE regress_createdb CREATEDB;
|
|
|
|
|
|
|
|
|
|
-- fail, can't toggle SUPERUSER
|
|
|
|
|
ALTER ROLE regress_createdb SUPERUSER;
|
|
|
|
|
ALTER ROLE regress_createdb NOSUPERUSER;
|
|
|
|
|
|
|
|
|
|
-- ok, having CREATEROLE is enough to create users with these privileges
|
Restrict the privileges of CREATEROLE users.
Previously, CREATEROLE users were permitted to make nearly arbitrary
changes to roles that they didn't create, with certain exceptions,
particularly superuser roles. Instead, allow CREATEROLE users to make such
changes to roles for which they possess ADMIN OPTION, and to
grant membership only in roles for which they possess ADMIN OPTION.
When a CREATEROLE user who is not a superuser creates a role, grant
ADMIN OPTION on the newly-created role to the creator, so that they
can administer roles they create or for which they have been given
privileges.
With these changes, CREATEROLE users still have very significant
powers that unprivileged users do not receive: they can alter, rename,
drop, comment on, change the password for, and change security labels
on roles. However, they can now do these things only for roles for
which they possess appropriate privileges, rather than all
non-superuser roles; moreover, they cannot grant a role such as
pg_execute_server_program unless they themselves possess it.
Patch by me, reviewed by Mark Dilger.
Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com
2023-01-10 12:44:30 -05:00
|
|
|
CREATE ROLE regress_createrole CREATEROLE NOINHERIT;
|
2023-01-10 12:44:49 -05:00
|
|
|
GRANT CREATE ON DATABASE regression TO regress_createrole WITH GRANT OPTION;
|
2022-01-24 15:25:27 -05:00
|
|
|
CREATE ROLE regress_login LOGIN;
|
|
|
|
|
CREATE ROLE regress_inherit INHERIT;
|
|
|
|
|
CREATE ROLE regress_connection_limit CONNECTION LIMIT 5;
|
|
|
|
|
CREATE ROLE regress_encrypted_password ENCRYPTED PASSWORD 'foo';
|
|
|
|
|
CREATE ROLE regress_password_null PASSWORD NULL;
|
|
|
|
|
|
|
|
|
|
-- ok, backwards compatible noise words should be ignored
|
|
|
|
|
CREATE ROLE regress_noiseword SYSID 12345;
|
|
|
|
|
|
|
|
|
|
-- fail, cannot grant membership in superuser role
|
|
|
|
|
CREATE ROLE regress_nosuch_super IN ROLE regress_role_super;
|
|
|
|
|
|
|
|
|
|
-- fail, database owner cannot have members
|
|
|
|
|
CREATE ROLE regress_nosuch_dbowner IN ROLE pg_database_owner;
|
|
|
|
|
|
|
|
|
|
-- ok, can grant other users into a role
|
|
|
|
|
CREATE ROLE regress_inroles ROLE
|
|
|
|
|
regress_role_super, regress_createdb, regress_createrole, regress_login,
|
|
|
|
|
regress_inherit, regress_connection_limit, regress_encrypted_password, regress_password_null;
|
|
|
|
|
|
|
|
|
|
-- fail, cannot grant a role into itself
|
|
|
|
|
CREATE ROLE regress_nosuch_recursive ROLE regress_nosuch_recursive;
|
|
|
|
|
|
|
|
|
|
-- ok, can grant other users into a role with admin option
|
|
|
|
|
CREATE ROLE regress_adminroles ADMIN
|
|
|
|
|
regress_role_super, regress_createdb, regress_createrole, regress_login,
|
|
|
|
|
regress_inherit, regress_connection_limit, regress_encrypted_password, regress_password_null;
|
|
|
|
|
|
|
|
|
|
-- fail, cannot grant a role into itself with admin option
|
|
|
|
|
CREATE ROLE regress_nosuch_admin_recursive ADMIN regress_nosuch_admin_recursive;
|
|
|
|
|
|
|
|
|
|
-- fail, regress_createrole does not have CREATEDB privilege
|
|
|
|
|
SET SESSION AUTHORIZATION regress_createrole;
|
|
|
|
|
CREATE DATABASE regress_nosuch_db;
|
|
|
|
|
|
|
|
|
|
-- ok, regress_createrole can create new roles
|
|
|
|
|
CREATE ROLE regress_plainrole;
|
|
|
|
|
|
|
|
|
|
-- ok, roles with CREATEROLE can create new roles with it
|
|
|
|
|
CREATE ROLE regress_rolecreator CREATEROLE;
|
|
|
|
|
|
Adjust interaction of CREATEROLE with role properties.
Previously, a CREATEROLE user without SUPERUSER could not alter
REPLICATION users in any way, and could not set the BYPASSRLS
attribute. However, they could manipulate the CREATEDB property
even if they themselves did not possess it.
With this change, a CREATEROLE user without SUPERUSER can set or
clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new
role or a role that they have rights to manage if and only if
that property is set for their own role.
This implements the standard idea that you can't give permissions
you don't have (but you can give the ones you do have). We might
in the future want to provide more powerful ways to constrain
what a CREATEROLE user can do - for example, to limit whether
CONNECTION LIMIT can be set or the values to which it can be set -
but that is left as future work.
Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha
Sharma.
Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 10:57:09 -05:00
|
|
|
-- ok, roles with CREATEROLE can create new roles with different role
|
|
|
|
|
-- attributes, including CREATEROLE
|
|
|
|
|
CREATE ROLE regress_hasprivs CREATEROLE LOGIN INHERIT CONNECTION LIMIT 5;
|
Restrict the privileges of CREATEROLE users.
Previously, CREATEROLE users were permitted to make nearly arbitrary
changes to roles that they didn't create, with certain exceptions,
particularly superuser roles. Instead, allow CREATEROLE users to make such
changes to roles for which they possess ADMIN OPTION, and to
grant membership only in roles for which they possess ADMIN OPTION.
When a CREATEROLE user who is not a superuser creates a role, grant
ADMIN OPTION on the newly-created role to the creator, so that they
can administer roles they create or for which they have been given
privileges.
With these changes, CREATEROLE users still have very significant
powers that unprivileged users do not receive: they can alter, rename,
drop, comment on, change the password for, and change security labels
on roles. However, they can now do these things only for roles for
which they possess appropriate privileges, rather than all
non-superuser roles; moreover, they cannot grant a role such as
pg_execute_server_program unless they themselves possess it.
Patch by me, reviewed by Mark Dilger.
Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com
2023-01-10 12:44:30 -05:00
|
|
|
|
|
|
|
|
-- ok, we should be able to modify a role we created
|
|
|
|
|
COMMENT ON ROLE regress_hasprivs IS 'some comment';
|
|
|
|
|
ALTER ROLE regress_hasprivs RENAME TO regress_tenant;
|
|
|
|
|
ALTER ROLE regress_tenant NOINHERIT NOLOGIN CONNECTION LIMIT 7;
|
|
|
|
|
|
|
|
|
|
-- fail, we should be unable to modify a role we did not create
|
|
|
|
|
COMMENT ON ROLE regress_role_normal IS 'some comment';
|
|
|
|
|
ALTER ROLE regress_role_normal RENAME TO regress_role_abnormal;
|
|
|
|
|
ALTER ROLE regress_role_normal NOINHERIT NOLOGIN CONNECTION LIMIT 7;
|
2022-01-24 15:25:27 -05:00
|
|
|
|
|
|
|
|
-- ok, regress_tenant can create objects within the database
|
|
|
|
|
SET SESSION AUTHORIZATION regress_tenant;
|
|
|
|
|
CREATE TABLE tenant_table (i integer);
|
|
|
|
|
CREATE INDEX tenant_idx ON tenant_table(i);
|
|
|
|
|
CREATE VIEW tenant_view AS SELECT * FROM pg_catalog.pg_class;
|
|
|
|
|
REVOKE ALL PRIVILEGES ON tenant_table FROM PUBLIC;
|
|
|
|
|
|
|
|
|
|
-- fail, these objects belonging to regress_tenant
|
|
|
|
|
SET SESSION AUTHORIZATION regress_createrole;
|
|
|
|
|
DROP INDEX tenant_idx;
|
|
|
|
|
ALTER TABLE tenant_table ADD COLUMN t text;
|
|
|
|
|
DROP TABLE tenant_table;
|
|
|
|
|
ALTER VIEW tenant_view OWNER TO regress_role_admin;
|
|
|
|
|
DROP VIEW tenant_view;
|
|
|
|
|
|
2023-01-10 12:44:49 -05:00
|
|
|
-- fail, can't create objects owned as regress_tenant
|
|
|
|
|
CREATE SCHEMA regress_tenant_schema AUTHORIZATION regress_tenant;
|
|
|
|
|
|
Restrict the privileges of CREATEROLE users.
Previously, CREATEROLE users were permitted to make nearly arbitrary
changes to roles that they didn't create, with certain exceptions,
particularly superuser roles. Instead, allow CREATEROLE users to make such
changes to roles for which they possess ADMIN OPTION, and to
grant membership only in roles for which they possess ADMIN OPTION.
When a CREATEROLE user who is not a superuser creates a role, grant
ADMIN OPTION on the newly-created role to the creator, so that they
can administer roles they create or for which they have been given
privileges.
With these changes, CREATEROLE users still have very significant
powers that unprivileged users do not receive: they can alter, rename,
drop, comment on, change the password for, and change security labels
on roles. However, they can now do these things only for roles for
which they possess appropriate privileges, rather than all
non-superuser roles; moreover, they cannot grant a role such as
pg_execute_server_program unless they themselves possess it.
Patch by me, reviewed by Mark Dilger.
Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com
2023-01-10 12:44:30 -05:00
|
|
|
-- fail, we don't inherit permissions from regress_tenant
|
2022-01-24 15:25:27 -05:00
|
|
|
REASSIGN OWNED BY regress_tenant TO regress_createrole;
|
|
|
|
|
|
2023-01-10 12:44:49 -05:00
|
|
|
-- ok, create a role with a value for createrole_self_grant
|
|
|
|
|
SET createrole_self_grant = 'set, inherit';
|
|
|
|
|
CREATE ROLE regress_tenant2;
|
|
|
|
|
GRANT CREATE ON DATABASE regression TO regress_tenant2;
|
|
|
|
|
|
|
|
|
|
-- ok, regress_tenant2 can create objects within the database
|
|
|
|
|
SET SESSION AUTHORIZATION regress_tenant2;
|
|
|
|
|
CREATE TABLE tenant2_table (i integer);
|
|
|
|
|
REVOKE ALL PRIVILEGES ON tenant2_table FROM PUBLIC;
|
|
|
|
|
|
|
|
|
|
-- ok, because we have SET and INHERIT on regress_tenant2
|
|
|
|
|
SET SESSION AUTHORIZATION regress_createrole;
|
|
|
|
|
CREATE SCHEMA regress_tenant2_schema AUTHORIZATION regress_tenant2;
|
|
|
|
|
ALTER SCHEMA regress_tenant2_schema OWNER TO regress_createrole;
|
|
|
|
|
ALTER TABLE tenant2_table OWNER TO regress_createrole;
|
|
|
|
|
ALTER TABLE tenant2_table OWNER TO regress_tenant2;
|
|
|
|
|
|
|
|
|
|
-- with SET but not INHERIT, we can give away objects but not take them
|
|
|
|
|
REVOKE INHERIT OPTION FOR regress_tenant2 FROM regress_createrole;
|
|
|
|
|
ALTER SCHEMA regress_tenant2_schema OWNER TO regress_tenant2;
|
|
|
|
|
ALTER TABLE tenant2_table OWNER TO regress_createrole;
|
|
|
|
|
|
|
|
|
|
-- with INHERIT but not SET, we can take objects but not give them away
|
|
|
|
|
GRANT regress_tenant2 TO regress_createrole WITH INHERIT TRUE, SET FALSE;
|
|
|
|
|
ALTER TABLE tenant2_table OWNER TO regress_createrole;
|
|
|
|
|
ALTER TABLE tenant2_table OWNER TO regress_tenant2;
|
|
|
|
|
DROP TABLE tenant2_table;
|
|
|
|
|
|
Restrict the privileges of CREATEROLE users.
Previously, CREATEROLE users were permitted to make nearly arbitrary
changes to roles that they didn't create, with certain exceptions,
particularly superuser roles. Instead, allow CREATEROLE users to make such
changes to roles for which they possess ADMIN OPTION, and to
grant membership only in roles for which they possess ADMIN OPTION.
When a CREATEROLE user who is not a superuser creates a role, grant
ADMIN OPTION on the newly-created role to the creator, so that they
can administer roles they create or for which they have been given
privileges.
With these changes, CREATEROLE users still have very significant
powers that unprivileged users do not receive: they can alter, rename,
drop, comment on, change the password for, and change security labels
on roles. However, they can now do these things only for roles for
which they possess appropriate privileges, rather than all
non-superuser roles; moreover, they cannot grant a role such as
pg_execute_server_program unless they themselves possess it.
Patch by me, reviewed by Mark Dilger.
Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com
2023-01-10 12:44:30 -05:00
|
|
|
-- fail, CREATEROLE is not enough to create roles in privileged roles
|
2022-01-24 15:25:27 -05:00
|
|
|
CREATE ROLE regress_read_all_data IN ROLE pg_read_all_data;
|
|
|
|
|
CREATE ROLE regress_write_all_data IN ROLE pg_write_all_data;
|
|
|
|
|
CREATE ROLE regress_monitor IN ROLE pg_monitor;
|
|
|
|
|
CREATE ROLE regress_read_all_settings IN ROLE pg_read_all_settings;
|
|
|
|
|
CREATE ROLE regress_read_all_stats IN ROLE pg_read_all_stats;
|
|
|
|
|
CREATE ROLE regress_stat_scan_tables IN ROLE pg_stat_scan_tables;
|
|
|
|
|
CREATE ROLE regress_read_server_files IN ROLE pg_read_server_files;
|
|
|
|
|
CREATE ROLE regress_write_server_files IN ROLE pg_write_server_files;
|
|
|
|
|
CREATE ROLE regress_execute_server_program IN ROLE pg_execute_server_program;
|
|
|
|
|
CREATE ROLE regress_signal_backend IN ROLE pg_signal_backend;
|
|
|
|
|
|
Restrict the privileges of CREATEROLE users.
Previously, CREATEROLE users were permitted to make nearly arbitrary
changes to roles that they didn't create, with certain exceptions,
particularly superuser roles. Instead, allow CREATEROLE users to make such
changes to roles for which they possess ADMIN OPTION, and to
grant membership only in roles for which they possess ADMIN OPTION.
When a CREATEROLE user who is not a superuser creates a role, grant
ADMIN OPTION on the newly-created role to the creator, so that they
can administer roles they create or for which they have been given
privileges.
With these changes, CREATEROLE users still have very significant
powers that unprivileged users do not receive: they can alter, rename,
drop, comment on, change the password for, and change security labels
on roles. However, they can now do these things only for roles for
which they possess appropriate privileges, rather than all
non-superuser roles; moreover, they cannot grant a role such as
pg_execute_server_program unless they themselves possess it.
Patch by me, reviewed by Mark Dilger.
Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com
2023-01-10 12:44:30 -05:00
|
|
|
-- fail, role still owns database objects
|
|
|
|
|
DROP ROLE regress_tenant;
|
|
|
|
|
|
2022-01-24 15:25:27 -05:00
|
|
|
-- fail, creation of these roles failed above so they do not now exist
|
|
|
|
|
SET SESSION AUTHORIZATION regress_role_admin;
|
|
|
|
|
DROP ROLE regress_nosuch_superuser;
|
|
|
|
|
DROP ROLE regress_nosuch_replication_bypassrls;
|
|
|
|
|
DROP ROLE regress_nosuch_replication;
|
|
|
|
|
DROP ROLE regress_nosuch_bypassrls;
|
|
|
|
|
DROP ROLE regress_nosuch_super;
|
|
|
|
|
DROP ROLE regress_nosuch_dbowner;
|
|
|
|
|
DROP ROLE regress_nosuch_recursive;
|
|
|
|
|
DROP ROLE regress_nosuch_admin_recursive;
|
|
|
|
|
DROP ROLE regress_plainrole;
|
|
|
|
|
|
2023-01-10 12:44:49 -05:00
|
|
|
-- must revoke privileges before dropping role
|
|
|
|
|
REVOKE CREATE ON DATABASE regression FROM regress_createrole CASCADE;
|
|
|
|
|
|
2022-01-24 15:25:27 -05:00
|
|
|
-- ok, should be able to drop non-superuser roles we created
|
Adjust interaction of CREATEROLE with role properties.
Previously, a CREATEROLE user without SUPERUSER could not alter
REPLICATION users in any way, and could not set the BYPASSRLS
attribute. However, they could manipulate the CREATEDB property
even if they themselves did not possess it.
With this change, a CREATEROLE user without SUPERUSER can set or
clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new
role or a role that they have rights to manage if and only if
that property is set for their own role.
This implements the standard idea that you can't give permissions
you don't have (but you can give the ones you do have). We might
in the future want to provide more powerful ways to constrain
what a CREATEROLE user can do - for example, to limit whether
CONNECTION LIMIT can be set or the values to which it can be set -
but that is left as future work.
Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha
Sharma.
Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 10:57:09 -05:00
|
|
|
DROP ROLE regress_replication_bypassrls;
|
|
|
|
|
DROP ROLE regress_replication;
|
|
|
|
|
DROP ROLE regress_bypassrls;
|
2022-01-24 15:25:27 -05:00
|
|
|
DROP ROLE regress_createdb;
|
Make role grant system more consistent with other privileges.
Previously, membership of role A in role B could be recorded in the
catalog tables only once. This meant that a new grant of role A to
role B would overwrite the previous grant. For other object types, a
new grant of permission on an object - in this case role A - exists
along side the existing grant provided that the grantor is different.
Either grant can be revoked independently of the other, and
permissions remain so long as at least one grant remains. Make role
grants work similarly.
Previously, when granting membership in a role, the superuser could
specify any role whatsoever as the grantor, but for other object types,
the grantor of record must be either the owner of the object, or a
role that currently has privileges to perform a similar GRANT.
Implement the same scheme for role grants, treating the bootstrap
superuser as the role owner since roles do not have owners. This means
that attempting to revoke a grant, or admin option on a grant, can now
fail if there are dependent privileges, and that CASCADE can be used
to revoke these. It also means that you can't grant ADMIN OPTION on
a role back to a user who granted it directly or indirectly to you,
similar to how you can't give WITH GRANT OPTION on a privilege back
to a role which granted it directly or indirectly to you.
Previously, only the superuser could specify GRANTED BY with a user
other than the current user. Relax that rule to allow the grantor
to be any role whose privileges the current user posseses. This
doesn't improve compatibility with what we do for other object types,
where support for GRANTED BY is entirely vestigial, but it makes this
feature more usable and seems to make sense to change at the same time
we're changing related behaviors.
Along the way, fix "ALTER GROUP group_name ADD USER user_name" to
require the same privileges as "GRANT group_name TO user_name".
Previously, CREATEROLE privileges were sufficient for either, but
only the former form was permissible with ADMIN OPTION on the role.
Now, either CREATEROLE or ADMIN OPTION on the role suffices for
either spelling.
Patch by me, reviewed by Stephen Frost.
Discussion: http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com
2022-08-22 11:35:17 -04:00
|
|
|
DROP ROLE regress_createrole;
|
2022-01-24 15:25:27 -05:00
|
|
|
DROP ROLE regress_login;
|
|
|
|
|
DROP ROLE regress_inherit;
|
|
|
|
|
DROP ROLE regress_connection_limit;
|
|
|
|
|
DROP ROLE regress_encrypted_password;
|
|
|
|
|
DROP ROLE regress_password_null;
|
|
|
|
|
DROP ROLE regress_noiseword;
|
|
|
|
|
DROP ROLE regress_inroles;
|
|
|
|
|
DROP ROLE regress_adminroles;
|
|
|
|
|
|
2023-01-11 12:22:47 -05:00
|
|
|
-- fail, cannot drop ourself, nor superusers or roles we lack ADMIN for
|
2022-01-24 15:25:27 -05:00
|
|
|
DROP ROLE regress_role_super;
|
|
|
|
|
DROP ROLE regress_role_admin;
|
2023-01-11 12:22:47 -05:00
|
|
|
DROP ROLE regress_rolecreator;
|
2022-01-24 15:25:27 -05:00
|
|
|
|
|
|
|
|
-- ok
|
|
|
|
|
RESET SESSION AUTHORIZATION;
|
2023-01-10 12:44:49 -05:00
|
|
|
REVOKE CREATE ON DATABASE regression FROM regress_role_admin CASCADE;
|
2022-01-24 15:25:27 -05:00
|
|
|
DROP INDEX tenant_idx;
|
|
|
|
|
DROP TABLE tenant_table;
|
|
|
|
|
DROP VIEW tenant_view;
|
2023-01-11 12:22:47 -05:00
|
|
|
DROP SCHEMA regress_tenant2_schema;
|
2024-01-28 18:05:59 -05:00
|
|
|
-- check for duplicated drop
|
|
|
|
|
DROP ROLE regress_tenant, regress_tenant;
|
2023-01-11 12:22:47 -05:00
|
|
|
DROP ROLE regress_tenant2;
|
|
|
|
|
DROP ROLE regress_rolecreator;
|
2022-01-24 15:25:27 -05:00
|
|
|
DROP ROLE regress_role_admin;
|
2023-01-26 08:14:41 -05:00
|
|
|
DROP ROLE regress_role_limited_admin;
|
2022-01-24 15:25:27 -05:00
|
|
|
DROP ROLE regress_role_super;
|
Restrict the privileges of CREATEROLE users.
Previously, CREATEROLE users were permitted to make nearly arbitrary
changes to roles that they didn't create, with certain exceptions,
particularly superuser roles. Instead, allow CREATEROLE users to make such
changes to roles for which they possess ADMIN OPTION, and to
grant membership only in roles for which they possess ADMIN OPTION.
When a CREATEROLE user who is not a superuser creates a role, grant
ADMIN OPTION on the newly-created role to the creator, so that they
can administer roles they create or for which they have been given
privileges.
With these changes, CREATEROLE users still have very significant
powers that unprivileged users do not receive: they can alter, rename,
drop, comment on, change the password for, and change security labels
on roles. However, they can now do these things only for roles for
which they possess appropriate privileges, rather than all
non-superuser roles; moreover, they cannot grant a role such as
pg_execute_server_program unless they themselves possess it.
Patch by me, reviewed by Mark Dilger.
Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com
2023-01-10 12:44:30 -05:00
|
|
|
DROP ROLE regress_role_normal;
|