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 1ohWGg-0000sE-CR for pgsql-docs@arkaria.postgresql.org; Sun, 09 Oct 2022 13:22:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ohWFf-000128-SC for pgsql-docs@arkaria.postgresql.org; Sun, 09 Oct 2022 13:21:55 +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 1ohWFf-00011z-C3 for pgsql-docs@lists.postgresql.org; Sun, 09 Oct 2022 13:21:55 +0000 Received: from mail-qk1-x732.google.com ([2607:f8b0:4864:20::732]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ohWFY-0006Vl-U0 for pgsql-docs@lists.postgresql.org; Sun, 09 Oct 2022 13:21:54 +0000 Received: by mail-qk1-x732.google.com with SMTP id x25so1775439qki.2 for ; Sun, 09 Oct 2022 06:21:48 -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 :message-id:reply-to; bh=XWk3Ke8GMNcnxGdWTow+7i5Zo7rlVJUQBjuqkHAGI/c=; b=KS7RaDXByAKBaMKnc5iHVHWajaKCkQ+JGUQ2h1hnDHSf8F0wAxO0M1IMksie2TmRcZ /Y+rz9EibztctJQmwrH6/+WYI3oGGhWbTvkVKQqK9ZrqZFyFstY2VA+wBqnEDY/pOxqn a5v4m5CYVat5DyCTYZQz6itBfZ1sR1Jpk81EA= 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:message-id:reply-to; bh=XWk3Ke8GMNcnxGdWTow+7i5Zo7rlVJUQBjuqkHAGI/c=; b=ne74jERzxZVF3WcOlTO2wfxpRCWez1gy0sSZUCAUFCBAXnrkbLO3wHh5+MoptnRtM8 Wyt6RO+cl6KuPn/cuM+OT4JGYklr0Ym4qacy9iuvX2534kZZtpvHAqVqXiTTjM8daYtA kXqkM1noIxM88B2ZJGawaJThZjGk0yReekFIx8LmflOUjhTGVmxZCm7hoKn8Lk8k9Eur KW6XOzaTAqdR/MIxfLMGw/t3DD1D9muFeMSRim1ieoCqcC0wki7aIhhhfODj85DxSbxn Z8ZNWCe05/fwXlKmDr5i3daCQU1zE5LuIucvJHzoaQ/Qh0OJX8oTHj+ru5o4jCQtlCh+ mNDw== X-Gm-Message-State: ACrzQf1O12pkMsecPvzP4zOo448Z9ibT7iZsQ9phIqRk0opW9GvIYE/w 5eSZO7WOv8OMO2/k9xWKP/wBqg== X-Google-Smtp-Source: AMsMyM7g03VkAVJlqgHTc4ZJDqJ+feG7VndBQ2knSbsy7XS+kz/C1JYcKHwtR7Yc4eIOnOje85znVA== X-Received: by 2002:a05:620a:1a04:b0:6ce:abb7:d6e8 with SMTP id bk4-20020a05620a1a0400b006ceabb7d6e8mr9658356qkb.296.1665321706944; Sun, 09 Oct 2022 06:21:46 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id v16-20020a05620a441000b006e8f8ca8287sm6679441qkp.120.2022.10.09.06.21.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Oct 2022 06:21:46 -0700 (PDT) Date: Sun, 9 Oct 2022 06:21:43 -0700 From: Noah Misch To: Bruce Momjian Cc: Erki Eessaar , "pgsql-docs@lists.postgresql.org" , Peter Eisentraut Subject: Re: SQL-standard function bodies and creating SECURITY DEFINER routines securely Message-ID: <20221009132143.GA2391199@rfd.leadboat.com> References: 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 Fri, Oct 07, 2022 at 09:35:49AM -0400, Bruce Momjian wrote: > On Fri, Oct 7, 2022 at 08:05:36AM +0000, Erki Eessaar wrote: > > I confirmed, that setting search_path is indeed sometimes needed in case of > > SECURITY DEFINER routines that have SQL-standard bodies. See an example at the > > end of the letter. > > > > I suggest the following paragraph to the documentation: > > > > Starting from PostgreSQL 14 SQL-standard bodies can be used in SQL-language > > functions. This form tracks dependencies between the function and objects used > > in the function body. However, there is still a possibility that such function > > calls other code that reacts to search path. Thus, as a best practice, SECURITY > > DEFINER functions with SQL-standard bodies should also override search_path. > > I think this gets back to what Noah said about this section not needing > to explain all the details but rather give general guidance. I am not > sure adding the reasons for _why_ you should use search path for > SQL-standard bodies is really adding anything. Noah, is that accurate? Yes, that's my thinking. It's hard to make objective decisions about how deeply to cover each topic in the documentation. I'm content with the present state of this particular section, though.