Skip to content

Commit be062bf

Browse files
committed
Fix per-session activation of ALTER {ROLE|DATABASE} SET role.
After commit 5a2fed9, the catalog state resulting from these commands ceased to affect sessions. Restore the longstanding behavior, which is like beginning the session with a SET ROLE command. If cherry-picking the CVE-2024-10978 fixes, default to including this, too. (This fixes an unintended side effect of fixing CVE-2024-10978.) Back-patch to v12, like that commit. The release team decided to include v12, despite the original intent to halt v12 commits earlier this week. Tom Lane and Noah Misch. Reported by Etienne LAFARGE. Discussion: https://postgr.es/m/CADOZwSb0UsEr4_UTFXC5k7=fyyK8uKXekucd+-uuGjJsGBfxgw@mail.gmail.com
1 parent 26c4e89 commit be062bf

File tree

5 files changed

+87
-3
lines changed

5 files changed

+87
-3
lines changed

src/backend/utils/init/miscinit.c

+19-1
Original file line numberDiff line numberDiff line change
@@ -775,7 +775,25 @@ InitializeSessionUserId(const char *rolename, Oid roleid)
775775
{
776776
SetAuthenticatedUserId(roleid, is_superuser);
777777

778-
/* Set SessionUserId and related variables via the GUC mechanisms */
778+
/*
779+
* Set SessionUserId and related variables, including "role", via the
780+
* GUC mechanisms.
781+
*
782+
* Note: ideally we would use PGC_S_DYNAMIC_DEFAULT here, so that
783+
* session_authorization could subsequently be changed from
784+
* pg_db_role_setting entries. Instead, session_authorization in
785+
* pg_db_role_setting has no effect. Changing that would require
786+
* solving two problems:
787+
*
788+
* 1. If pg_db_role_setting has values for both session_authorization
789+
* and role, we could not be sure which order those would be applied
790+
* in, and it would matter.
791+
*
792+
* 2. Sites may have years-old session_authorization entries. There's
793+
* not been any particular reason to remove them. Ending the dormancy
794+
* of those entries could seriously change application behavior, so
795+
* only a major release should do that.
796+
*/
779797
SetConfigOption("session_authorization", rname,
780798
PGC_BACKEND, PGC_S_OVERRIDE);
781799
}

src/backend/utils/misc/guc.c

+9-1
Original file line numberDiff line numberDiff line change
@@ -7937,6 +7937,12 @@ set_config_option(const char *name, const char *value,
79377937
* expect that if "role" isn't supposed to be default, it
79387938
* has been or will be set by a separate reload action.
79397939
*
7940+
* Also, for the call from InitializeSessionUserId with
7941+
* source == PGC_S_OVERRIDE, use PGC_S_DYNAMIC_DEFAULT for
7942+
* "role"'s source, so that it's still possible to set
7943+
* "role" from pg_db_role_setting entries. (See notes in
7944+
* InitializeSessionUserId before changing this.)
7945+
*
79407946
* A fine point: for RESET session_authorization, we do
79417947
* "RESET role" not "SET ROLE NONE" (by passing down NULL
79427948
* rather than "none" for the value). This would have the
@@ -7949,7 +7955,9 @@ set_config_option(const char *name, const char *value,
79497955
(void) set_config_option("role",
79507956
value ? "none" : NULL,
79517957
orig_context,
7952-
orig_source,
7958+
(orig_source == PGC_S_OVERRIDE)
7959+
? PGC_S_DYNAMIC_DEFAULT
7960+
: orig_source,
79537961
action,
79547962
true,
79557963
elevel,

src/test/modules/unsafe_tests/Makefile

+4-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,9 @@
11
# src/test/modules/unsafe_tests/Makefile
22

3-
REGRESS = rolenames alter_system_table
3+
REGRESS = rolenames setconfig alter_system_table
4+
REGRESS_OPTS = \
5+
--create-role=regress_authenticated_user_sr \
6+
--create-role=regress_authenticated_user_ssa
47

58
# the whole point of these tests is to not run installcheck
69
NO_INSTALLCHECK = 1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
-- This is borderline unsafe in that an additional login-capable user exists
2+
-- during the test run. Under installcheck, a too-permissive pg_hba.conf
3+
-- might allow unwanted logins as regress_authenticated_user_ssa.
4+
ALTER USER regress_authenticated_user_ssa superuser;
5+
CREATE ROLE regress_session_user;
6+
CREATE ROLE regress_current_user;
7+
GRANT regress_current_user TO regress_authenticated_user_sr;
8+
GRANT regress_session_user TO regress_authenticated_user_ssa;
9+
ALTER ROLE regress_authenticated_user_ssa
10+
SET session_authorization = regress_session_user;
11+
ALTER ROLE regress_authenticated_user_sr SET ROLE = regress_current_user;
12+
\c - regress_authenticated_user_sr
13+
SELECT current_user, session_user;
14+
current_user | session_user
15+
----------------------+-------------------------------
16+
regress_current_user | regress_authenticated_user_sr
17+
(1 row)
18+
19+
-- The longstanding historical behavior is that session_authorization in
20+
-- setconfig has no effect. Hence, session_user remains
21+
-- regress_authenticated_user_ssa. See comment in InitializeSessionUserId().
22+
\c - regress_authenticated_user_ssa
23+
SELECT current_user, session_user;
24+
current_user | session_user
25+
--------------------------------+--------------------------------
26+
regress_authenticated_user_ssa | regress_authenticated_user_ssa
27+
(1 row)
28+
29+
RESET SESSION AUTHORIZATION;
30+
DROP USER regress_session_user;
31+
DROP USER regress_current_user;
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
-- This is borderline unsafe in that an additional login-capable user exists
2+
-- during the test run. Under installcheck, a too-permissive pg_hba.conf
3+
-- might allow unwanted logins as regress_authenticated_user_ssa.
4+
5+
ALTER USER regress_authenticated_user_ssa superuser;
6+
CREATE ROLE regress_session_user;
7+
CREATE ROLE regress_current_user;
8+
GRANT regress_current_user TO regress_authenticated_user_sr;
9+
GRANT regress_session_user TO regress_authenticated_user_ssa;
10+
ALTER ROLE regress_authenticated_user_ssa
11+
SET session_authorization = regress_session_user;
12+
ALTER ROLE regress_authenticated_user_sr SET ROLE = regress_current_user;
13+
14+
\c - regress_authenticated_user_sr
15+
SELECT current_user, session_user;
16+
17+
-- The longstanding historical behavior is that session_authorization in
18+
-- setconfig has no effect. Hence, session_user remains
19+
-- regress_authenticated_user_ssa. See comment in InitializeSessionUserId().
20+
\c - regress_authenticated_user_ssa
21+
SELECT current_user, session_user;
22+
RESET SESSION AUTHORIZATION;
23+
DROP USER regress_session_user;
24+
DROP USER regress_current_user;

0 commit comments

Comments
 (0)