Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXbLZ-0002ho-6q for pgsql-docs@arkaria.postgresql.org; Mon, 12 Sep 2022 04:47:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oXbLX-0008F7-Mw for pgsql-docs@arkaria.postgresql.org; Mon, 12 Sep 2022 04:46:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXbLX-0008Es-8N for pgsql-docs@lists.postgresql.org; Mon, 12 Sep 2022 04:46:59 +0000 Received: from mail-qv1-xf30.google.com ([2607:f8b0:4864:20::f30]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oXbLQ-0003pm-3t for pgsql-docs@lists.postgresql.org; Mon, 12 Sep 2022 04:46:58 +0000 Received: by mail-qv1-xf30.google.com with SMTP id w4so5934897qvp.2 for ; Sun, 11 Sep 2022 21:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=h4caKY4MxflhybVowoGQDiL+9WyYPz0Hpf7+JWN0xeI=; b=axNCO1pdpkdYar3WBcMODgK0vuBq8g15IVbsdejsqQpyG7evQqTeb3iQkq/3gjGAP5 29inmneAS4pipZVNpu8v7VoAUDo565aGRRE1kPjq+EvfE67xJ2G379t+90qGcOQwBK3b tcIx5E3S/j79H7r11B4zPSF+X2F4Dtbh9wj5Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=h4caKY4MxflhybVowoGQDiL+9WyYPz0Hpf7+JWN0xeI=; b=xzk0cm55vsQJkYFXcUGvSF6k9QKscVG2eGLjDWt2LiAIstJ5wif6f9stRz0f+xHBGV hf2/20ydmFv6VbS9Rj81CWCZs4Qt7SlzAL19syN6/KZ9W2oyzIy1fkDVvjSYOVNbOK/Y J4EKqH3WIayMn4yeyyJ17YK8JvQrvGVsytam8kkC5MHcGWNPIpVS/3cNAGg7LuB3+7z1 FApTlYfJPiFVWq1iBblP0DLz3ZNHDDh3ZSpB0TOMuSIPtyfcUWVJlCMQdlW3JyoPft8H Vym2mKgIskkajlcYiW7rmha30Xw5zsD1VaESw+QGW2B5qD4wKEXH4ljDlSaPD9Z2MuKK jXLg== X-Gm-Message-State: ACgBeo046kVhZwlBCddBbLBRH/FhC5+81g5xLqiP1QSBpcXCMtEb/S4S Rb3g3Gqd4OVHOTImjQxsis4RDA== X-Google-Smtp-Source: AA6agR4CnTWPXWHStD4o3kOjhXoJ41aGOs7WzSSLtozdNcC3R8sfnLW5SA/DC+3HhvIkVcnhgIsPvw== X-Received: by 2002:a0c:e24b:0:b0:4a1:d41b:e280 with SMTP id x11-20020a0ce24b000000b004a1d41be280mr21578046qvl.11.1662958010238; Sun, 11 Sep 2022 21:46:50 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id w28-20020a05622a191c00b0034454aff529sm5604246qtc.80.2022.09.11.21.46.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Sep 2022 21:46:49 -0700 (PDT) Date: Sun, 11 Sep 2022 21:46:47 -0700 From: Noah Misch To: Bruce Momjian , Peter Eisentraut Cc: Tom Lane , Erki Eessaar , "pgsql-docs@lists.postgresql.org" Subject: Re: SQL-standard function bodies and creating SECURITY DEFINER routines securely Message-ID: <20220912044647.GA1404410@rfd.leadboat.com> References: <1408823.1660678462@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Sep 08, 2022 at 01:20:31PM +0200, Peter Eisentraut wrote: > On 01.09.22 03:11, Bruce Momjian wrote: > >On Tue, Aug 16, 2022 at 03:38:13PM -0400, Bruce Momjian wrote: > >>On Tue, Aug 16, 2022 at 03:34:22PM -0400, Tom Lane wrote: > >>>Bruce Momjian writes: > >>>>I have written the attached patch to mention this issue about sql_body > >>>>functions. > >>> > >>>Spell-check, please. Seems OK otherwise. > >Patch applied back to PG 10. Thanks. > > This feature is new in PG 14, so backpatching further than that doesn't make > sense. Even an sql_body function should override search_path, because it may call other code that reacts to search_path. Separately, the new sentence is near the start of a section that addresses more than just search_path. The section ends with the "revoke the default PUBLIC privileges" topic, which is no less relevant to sql_body functions. Documentation needn't explain cases that make a best practice optional, and it should explain only valuable ones. Omitting search_path on sql_body SECURITY DEFINER functions isn't that valuable. If it were valuable, the patch's sentence gives too little detail for the reader to decide what's safe for a given function. I think this section should not attempt such detail. It's enough to give the best practice, as the documentation did before this change.