summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane2024-11-11 22:05:53 +0000
committerTom Lane2024-11-11 22:05:53 +0000
commit73c9f91a1b6d3753451993c5f06ba4b5ccc1f127 (patch)
tree0cf4847f955e41c4b9fcca14ce2f3ec7d6a8770a
parentc4252c9ef0afea48a59402901c16fc970d838721 (diff)
Parallel workers use AuthenticatedUserId for connection privilege checks.
Commit 5a2fed911 had an unexpected side-effect: the parallel worker launched for the new test case would fail if it couldn't use a superuser-reserved connection slot. The reason that test failed while all our pre-existing ones worked is that the connection privilege tests in InitPostgres had been based on the superuserness of the leader's AuthenticatedUserId, but after the rearrangements of 5a2fed911 we were testing the superuserness of CurrentUserId, which the new test case deliberately made to be a non-superuser. This all seems very accidental and probably not the behavior we really want, but a security patch is no time to be redesigning things. Pending some discussion about desirable semantics, hack it so that InitPostgres continues to pay attention to the superuserness of AuthenticatedUserId when starting a parallel worker. Nathan Bossart and Tom Lane, per buildfarm member sawshark. Security: CVE-2024-10978
-rw-r--r--src/backend/utils/init/postinit.c19
1 files changed, 18 insertions, 1 deletions
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index a024b1151d..5b657a3f13 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -22,6 +22,7 @@
#include "access/genam.h"
#include "access/heapam.h"
#include "access/htup_details.h"
+#include "access/parallel.h"
#include "access/session.h"
#include "access/tableam.h"
#include "access/xact.h"
@@ -875,7 +876,23 @@ InitPostgres(const char *in_dbname, Oid dboid,
{
InitializeSessionUserId(username, useroid,
(flags & INIT_PG_OVERRIDE_ROLE_LOGIN) != 0);
- am_superuser = superuser();
+
+ /*
+ * In a parallel worker, set am_superuser based on the
+ * authenticated user ID, not the current role. This is pretty
+ * dubious but it matches our historical behavior. Note that this
+ * value of am_superuser is used only for connection-privilege
+ * checks here and in CheckMyDatabase (we won't reach
+ * process_startup_options in a background worker).
+ *
+ * In other cases, there's been no opportunity for the current
+ * role to diverge from the authenticated user ID yet, so we can
+ * just rely on superuser() and avoid an extra catalog lookup.
+ */
+ if (InitializingParallelWorker)
+ am_superuser = superuser_arg(GetAuthenticatedUserId());
+ else
+ am_superuser = superuser();
}
}
else