Skip to content

Commit 07c6e0f

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 15dc1ab commit 07c6e0f

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
@@ -745,7 +745,25 @@ InitializeSessionUserId(const char *rolename, Oid roleid)
745745
{
746746
SetAuthenticatedUserId(roleid, is_superuser);
747747

748-
/* Set SessionUserId and related variables via the GUC mechanisms */
748+
/*
749+
* Set SessionUserId and related variables, including "role", via the
750+
* GUC mechanisms.
751+
*
752+
* Note: ideally we would use PGC_S_DYNAMIC_DEFAULT here, so that
753+
* session_authorization could subsequently be changed from
754+
* pg_db_role_setting entries. Instead, session_authorization in
755+
* pg_db_role_setting has no effect. Changing that would require
756+
* solving two problems:
757+
*
758+
* 1. If pg_db_role_setting has values for both session_authorization
759+
* and role, we could not be sure which order those would be applied
760+
* in, and it would matter.
761+
*
762+
* 2. Sites may have years-old session_authorization entries. There's
763+
* not been any particular reason to remove them. Ending the dormancy
764+
* of those entries could seriously change application behavior, so
765+
* only a major release should do that.
766+
*/
749767
SetConfigOption("session_authorization", rname,
750768
PGC_BACKEND, PGC_S_OVERRIDE);
751769
}

src/backend/utils/misc/guc.c

+9-1
Original file line numberDiff line numberDiff line change
@@ -7593,6 +7593,12 @@ set_config_option(const char *name, const char *value,
75937593
* expect that if "role" isn't supposed to be default, it
75947594
* has been or will be set by a separate reload action.
75957595
*
7596+
* Also, for the call from InitializeSessionUserId with
7597+
* source == PGC_S_OVERRIDE, use PGC_S_DYNAMIC_DEFAULT for
7598+
* "role"'s source, so that it's still possible to set
7599+
* "role" from pg_db_role_setting entries. (See notes in
7600+
* InitializeSessionUserId before changing this.)
7601+
*
75967602
* A fine point: for RESET session_authorization, we do
75977603
* "RESET role" not "SET ROLE NONE" (by passing down NULL
75987604
* rather than "none" for the value). This would have the
@@ -7605,7 +7611,9 @@ set_config_option(const char *name, const char *value,
76057611
(void) set_config_option("role",
76067612
value ? "none" : NULL,
76077613
orig_context,
7608-
orig_source,
7614+
(orig_source == PGC_S_OVERRIDE)
7615+
? PGC_S_DYNAMIC_DEFAULT
7616+
: orig_source,
76097617
action,
76107618
true,
76117619
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)