Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ewBuv-0003bO-S5 for pgsql-admin@arkaria.postgresql.org; Wed, 14 Mar 2018 19:18:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ewBuu-00037A-T0 for pgsql-admin@arkaria.postgresql.org; Wed, 14 Mar 2018 19:18:28 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ewBuu-00036v-IW for pgsql-admin@lists.postgresql.org; Wed, 14 Mar 2018 19:18:28 +0000 Received: from util-st-02.imsweb.com ([204.132.58.65]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ewBuq-0006m7-SX for pgsql-admin@lists.postgresql.org; Wed, 14 Mar 2018 19:18:26 +0000 Received: from PAN.omni.imsweb.com (haproxy-st-02 [204.132.58.76]) by util-st-02.imsweb.com (Postfix) with ESMTP id 98242E1498 for ; Wed, 14 Mar 2018 15:18:23 -0400 (EDT) Received: from THALASSA.omni.imsweb.com (172.22.64.102) by PAN.omni.imsweb.com (172.22.64.64) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 14 Mar 2018 15:18:23 -0400 Received: from THALASSA.omni.imsweb.com ([172.22.64.102]) by THALASSA.omni.imsweb.com ([172.22.64.102]) with mapi id 15.00.1365.000; Wed, 14 Mar 2018 15:18:23 -0400 From: "Heinemann, Manfred (IMS)" To: "pgsql-admin@lists.postgresql.org" Subject: Function search_path Thread-Topic: Function search_path Thread-Index: AdO7x5WpnFdOXZ+3TX2aPXuhH1G0VQ== Date: Wed, 14 Mar 2018 19:18:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [204.132.58.76] Content-Type: multipart/alternative; boundary="_000_db194d98f61d4aa398c1399a24326e7cTHALASSAomniimswebcom_" MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --_000_db194d98f61d4aa398c1399a24326e7cTHALASSAomniimswebcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We recently started upgrading to Postgres 10.3 and have run into trouble wi= th the security change to search_path. The release notes say: In cases where user-provided functions are indirectly executed by these pro= grams - for example, user-provided functions in index expressions - the tig= hter search_path may result in errors, which will need to be corrected by a= djusting those user-provided functions to not assume anything about what se= arch path they are invoked under. That has always been good practice, but n= ow it will be necessary for correct behavior. (CVE-2018-1058) We have this issue with a custom function that calls other custom functions= and that function is used in a functional index. Now autoanalyze and autov= acuum fail on tables with those indices. The simplest fix seemed to be to set the functions search_path to '$user' b= ut that has caused large updates to the indexed table to run out of memory. Hardcoding the schema in the function would mean having to have separate fu= nctions for each schema affected. It also seems to make the function less m= emory efficient. Are there other options? Thanks, Manfred ________________________________ Information in this e-mail may be confidential. It is intended only for the= addressee(s) identified above. If you are not the addressee(s), or an empl= oyee or agent of the addressee(s), please note that any dissemination, dist= ribution, or copying of this communication is strictly prohibited. If you h= ave received this e-mail in error, please notify the sender of the error. --_000_db194d98f61d4aa398c1399a24326e7cTHALASSAomniimswebcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We recently started upgrading to Postgres 10.3 and h= ave run into trouble with the security change to search_path.

 

The release notes say:

In cases where user-provided functions are indirectl= y executed by these programs — for example, user-provided functions i= n index expressions — the tighter search_path may result= in errors, which will need to be corrected by adjusting those user-provide= d functions to not assume anything about what search path they are invoked = under. That has always been good practice, but now it will be necessary for correct behavior. (CVE-2018-1058)

 

We have this issue with a custom function that calls= other custom functions and that function is used in a functional index. No= w autoanalyze and autovacuum fail on tables with those indices.<= /p>

 

The simplest fix seemed to be to set the functions s= earch_path to ‘$user’ but that has caused large updates to the = indexed table to run out of memory.

 

Hardcoding the schema in the function would mean hav= ing to have separate functions for each schema affected. It also seems to m= ake the function less memory efficient.

 

Are there other options?

 

Thanks,

Manfred



Information in this e-mail may be confidential. It is intended only for the= addressee(s) identified above. If you are not the addressee(s), or an empl= oyee or agent of the addressee(s), please note that any dissemination, dist= ribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please = notify the sender of the error.
 --_000_db194d98f61d4aa398c1399a24326e7cTHALASSAomniimswebcom_--