Fix per-session activation of ALTER {ROLE|DATABASE} SET role.
authorNoah Misch <noah@leadboat.com>
Sat, 16 Nov 2024 04:39:56 +0000 (20:39 -0800)
committerNoah Misch <noah@leadboat.com>
Sat, 16 Nov 2024 04:39:56 +0000 (20:39 -0800)
After commit 5a2fed911a85ed6d8a015a6bafe3a0d9a69334ae, 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

src/backend/utils/init/miscinit.c
src/backend/utils/misc/guc.c
src/test/modules/unsafe_tests/Makefile
src/test/modules/unsafe_tests/expected/setconfig.out [new file with mode: 0644]
src/test/modules/unsafe_tests/meson.build
src/test/modules/unsafe_tests/sql/setconfig.sql [new file with mode: 0644]

index 9e3676f7b3f39075614d30c12ffbbb133fb7f7a3..3b7b2ebec08d6cf9da3be7cc2713763d473f3cc2 100644 (file)
@@ -824,7 +824,25 @@ InitializeSessionUserId(const char *rolename, Oid roleid, bool bypass_login_chec
        {
                SetAuthenticatedUserId(roleid);
 
-               /* Set SessionUserId and related variables via the GUC mechanisms */
+               /*
+                * Set SessionUserId and related variables, including "role", via the
+                * GUC mechanisms.
+                *
+                * Note: ideally we would use PGC_S_DYNAMIC_DEFAULT here, so that
+                * session_authorization could subsequently be changed from
+                * pg_db_role_setting entries.  Instead, session_authorization in
+                * pg_db_role_setting has no effect.  Changing that would require
+                * solving two problems:
+                *
+                * 1. If pg_db_role_setting has values for both session_authorization
+                * and role, we could not be sure which order those would be applied
+                * in, and it would matter.
+                *
+                * 2. Sites may have years-old session_authorization entries.  There's
+                * not been any particular reason to remove them.  Ending the dormancy
+                * of those entries could seriously change application behavior, so
+                * only a major release should do that.
+                */
                SetConfigOption("session_authorization", rname,
                                                PGC_BACKEND, PGC_S_OVERRIDE);
        }
index 40e3bf7e91ead8c7e7157052c95dcd5dc81fb9c3..c10c0844ab6b6da231e7175ed2f9c7bb1e97c455 100644 (file)
@@ -4099,6 +4099,12 @@ set_config_with_handle(const char *name, config_handle *handle,
                                         * expect that if "role" isn't supposed to be default, it
                                         * has been or will be set by a separate reload action.
                                         *
+                                        * Also, for the call from InitializeSessionUserId with
+                                        * source == PGC_S_OVERRIDE, use PGC_S_DYNAMIC_DEFAULT for
+                                        * "role"'s source, so that it's still possible to set
+                                        * "role" from pg_db_role_setting entries.  (See notes in
+                                        * InitializeSessionUserId before changing this.)
+                                        *
                                         * A fine point: for RESET session_authorization, we do
                                         * "RESET role" not "SET ROLE NONE" (by passing down NULL
                                         * rather than "none" for the value).  This would have the
@@ -4111,7 +4117,9 @@ set_config_with_handle(const char *name, config_handle *handle,
                                                (void) set_config_with_handle("role", NULL,
                                                                                                          value ? "none" : NULL,
                                                                                                          orig_context,
-                                                                                                         orig_source,
+                                                                                                         (orig_source == PGC_S_OVERRIDE)
+                                                                                                         ? PGC_S_DYNAMIC_DEFAULT
+                                                                                                         : orig_source,
                                                                                                          orig_srole,
                                                                                                          action,
                                                                                                          true,
index 90d19791871c77dffbda5e0e0c9e218d289e6483..d4ff227ef079796241595acbd95baf00721bd7ae 100644 (file)
@@ -1,6 +1,9 @@
 # src/test/modules/unsafe_tests/Makefile
 
-REGRESS = rolenames alter_system_table guc_privs
+REGRESS = rolenames setconfig alter_system_table guc_privs
+REGRESS_OPTS = \
+       --create-role=regress_authenticated_user_sr \
+       --create-role=regress_authenticated_user_ssa
 
 # the whole point of these tests is to not run installcheck
 NO_INSTALLCHECK = 1
diff --git a/src/test/modules/unsafe_tests/expected/setconfig.out b/src/test/modules/unsafe_tests/expected/setconfig.out
new file mode 100644 (file)
index 0000000..6a021d9
--- /dev/null
@@ -0,0 +1,31 @@
+-- This is borderline unsafe in that an additional login-capable user exists
+-- during the test run.  Under installcheck, a too-permissive pg_hba.conf
+-- might allow unwanted logins as regress_authenticated_user_ssa.
+ALTER USER regress_authenticated_user_ssa superuser;
+CREATE ROLE regress_session_user;
+CREATE ROLE regress_current_user;
+GRANT regress_current_user TO regress_authenticated_user_sr;
+GRANT regress_session_user TO regress_authenticated_user_ssa;
+ALTER ROLE regress_authenticated_user_ssa
+       SET session_authorization = regress_session_user;
+ALTER ROLE regress_authenticated_user_sr SET ROLE = regress_current_user;
+\c - regress_authenticated_user_sr
+SELECT current_user, session_user;
+     current_user     |         session_user          
+----------------------+-------------------------------
+ regress_current_user | regress_authenticated_user_sr
+(1 row)
+
+-- The longstanding historical behavior is that session_authorization in
+-- setconfig has no effect.  Hence, session_user remains
+-- regress_authenticated_user_ssa.  See comment in InitializeSessionUserId().
+\c - regress_authenticated_user_ssa
+SELECT current_user, session_user;
+          current_user          |          session_user          
+--------------------------------+--------------------------------
+ regress_authenticated_user_ssa | regress_authenticated_user_ssa
+(1 row)
+
+RESET SESSION AUTHORIZATION;
+DROP USER regress_session_user;
+DROP USER regress_current_user;
index 3b0f606084677a58b1dfe07857512af8fa455908..3e174c7425af1c019adb96a9e2cb533ee0d28f8d 100644 (file)
@@ -7,9 +7,12 @@ tests += {
   'regress': {
     'sql': [
       'rolenames',
+      'setconfig',
       'alter_system_table',
       'guc_privs',
     ],
+    'regress_args': ['--create-role=regress_authenticated_user_sr',
+                     '--create-role=regress_authenticated_user_ssa'],
     'runningcheck': false,
   },
 }
diff --git a/src/test/modules/unsafe_tests/sql/setconfig.sql b/src/test/modules/unsafe_tests/sql/setconfig.sql
new file mode 100644 (file)
index 0000000..8817a7c
--- /dev/null
@@ -0,0 +1,24 @@
+-- This is borderline unsafe in that an additional login-capable user exists
+-- during the test run.  Under installcheck, a too-permissive pg_hba.conf
+-- might allow unwanted logins as regress_authenticated_user_ssa.
+
+ALTER USER regress_authenticated_user_ssa superuser;
+CREATE ROLE regress_session_user;
+CREATE ROLE regress_current_user;
+GRANT regress_current_user TO regress_authenticated_user_sr;
+GRANT regress_session_user TO regress_authenticated_user_ssa;
+ALTER ROLE regress_authenticated_user_ssa
+       SET session_authorization = regress_session_user;
+ALTER ROLE regress_authenticated_user_sr SET ROLE = regress_current_user;
+
+\c - regress_authenticated_user_sr
+SELECT current_user, session_user;
+
+-- The longstanding historical behavior is that session_authorization in
+-- setconfig has no effect.  Hence, session_user remains
+-- regress_authenticated_user_ssa.  See comment in InitializeSessionUserId().
+\c - regress_authenticated_user_ssa
+SELECT current_user, session_user;
+RESET SESSION AUTHORIZATION;
+DROP USER regress_session_user;
+DROP USER regress_current_user;