Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDQAy-000aX4-MQ for pgsql-admin@arkaria.postgresql.org; Tue, 19 Nov 2024 15:30:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tDQAx-00E23F-BT for pgsql-admin@arkaria.postgresql.org; Tue, 19 Nov 2024 15:29:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tD0ha-004pKn-L6 for pgsql-admin@lists.postgresql.org; Mon, 18 Nov 2024 12:17:59 +0000 Received: from mail-yb1-xb33.google.com ([2607:f8b0:4864:20::b33]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tD0hX-002VqA-3O for pgsql-admin@lists.postgresql.org; Mon, 18 Nov 2024 12:17:56 +0000 Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-e382ed3ee45so2456830276.0 for ; Mon, 18 Nov 2024 04:17:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731932274; x=1732537074; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=NtmEBiL1UzLV2Gv57j39fnfrIxM4+ihKy7dvfHiD6+s=; b=USzPr7AAKYMd0e7kWfK6ddLM7/UZISev0ueDAU16rQATbYCKFvMF+2dtSNJagqOSN1 cNP9PpZwOzv8BZwTzMQM1D83wW6QUw0THoJEfBYvTTfazkyi90gNYeX9uGLC/hg9mWWE VhEhAIey+0UwGA7xrfA9p9smXvfJH8lpjTd1Lv1oqjKmV5RTwsArcgb3W1sIPovr3zbh jqK/s5ZccKgPzCTrfSHAOGGmdVNXlBWrHUjSpwutwlV7wuUZ5KV0ogpUDh3VDbpmrhnE 7VwxJZ8vtjVyE7h1G2Y9IUFF5K/azBlgBqSgatDAMI1ZC/VsjIRl2nnOZLo36mrZdxif f8Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731932274; x=1732537074; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=NtmEBiL1UzLV2Gv57j39fnfrIxM4+ihKy7dvfHiD6+s=; b=YHR0dEoAH+8COFG14Qd/PKaFqmTwN24cHQJpkyrg5mNRHZB1xiMB50sCW+8ypj7NQd ePalUUvn3S5yi8t+D2eHjMWNwtTMYzK+8cV627xT4NK5oFEh4EAuEl0hFI14JLh3O0aS vk3YQLrEsz+W2PlFcGOS9u7yLYq7qmn/jgnNHI6ml50eUary2WdA9ke/vcK0+AJarb9X cg1FmNb2trt4AgD1EbZu5tjJCHfKrJid9LatCdtHkP2o/RXoAg3dk+OvHXfVFSCBVj10 0ciN5Rw5O2ehzOGOakKOsEbE6bYpTJHJOTKYd1Lj62WxgjpKxg3cMlN4/rZ+8L0xQ8wz D7ZA== X-Gm-Message-State: AOJu0YzvxZD/vJ/ysACg4tW13y3MCOQfeF34G4G9z1l1rterxFddIso5 eQWRy+L0q/v1UzHP8Cw/LoIlj2DWe+nmEP17ao3E04GIc3AQSxuZTNKVs9aYR6PqZoNb0nh36US hmkma9YZvPIyafvQxoIjBWkoD+UXb73O4Pyg= X-Google-Smtp-Source: AGHT+IGhqBQPQt2pDPrlL78aC1uhQBkudF4XagYTiVTL49dc8cDEfXnFJkeqVEuN8DVqMC1HS/uzHKqaWLC/B7B3O4I= X-Received: by 2002:a05:6902:188e:b0:e30:d383:9c24 with SMTP id 3f1490d57ef6-e3825d3e309mr9361922276.1.1731932274242; Mon, 18 Nov 2024 04:17:54 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?0JDQvdGC0L7QvSDQk9C70YPRiNCw0LrQvtCy?= Date: Mon, 18 Nov 2024 15:17:26 +0300 Message-ID: Subject: Broken behavior after minor update CVE-2024-10978 To: pgsql-admin@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000fb3a9206272ee7ec" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fb3a9206272ee7ec Content-Type: text/plain; charset="UTF-8" After upgrading to version 14.14, the behavior of roles related to the "set role" option broke. We actively use the feature "alter user set role db_role" in order to automatically change the role context upon login. But now this behavior has changed, and the context does not change, which unfortunately breaks all role-based access to data. If this was an abnormal behavior, is there an alternative way to automatically change the role context when connecting to the DB? --000000000000fb3a9206272ee7ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After upgrading to version 14.14, the behavior of roles re= lated to the "set role" option broke.
We actively use the feat= ure "alter user <username> set role db_role"
in order to= automatically change the role context upon login.
But n= ow this behavior has changed, and the context does not change, which unfort= unately breaks all role-based access to data.

If this was an abnor= mal behavior, is there an alternative way to automatically change the role = context when connecting to the DB?
--000000000000fb3a9206272ee7ec--