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 1qQb68-000OtP-Mx for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Jul 2023 22:10:41 +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 1qQb66-001zmG-9l for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Jul 2023 22:10:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQb65-001zm8-WC for pgsql-hackers@lists.postgresql.org; Mon, 31 Jul 2023 22:10:39 +0000 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qQb64-0004TA-PR for pgsql-hackers@postgresql.org; Mon, 31 Jul 2023 22:10:38 +0000 Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-686bc261111so3594798b3a.3 for ; Mon, 31 Jul 2023 15:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20221208.gappssmtp.com; s=20221208; t=1690841434; x=1691446234; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=DlAyd4Q7B78yLvEJKP2mUg3Nc7x+jQgLb2BqzOZvnGk=; b=X9O/ISULjSGPCLOO7996cvUG36137aw39y7RT4SqrVrkOvEy8GJjUWkM2Eduz7pqLE Qqu4djlo1EXQdvOtUgoUsGOqyQElXQizFaqwuoApT6XbiB+DBl9K9x91qApQfeYsLSPP 0mzS42xvV8AdW6CKrZgfLg6G4Om+pOgVMxI+MTQiTUGroqR2bZ9SO87ABQ1SxkqHYSPW /qfhQbgxp9/EwKBwrEo712QGp6NOshUuiCtuK8G898D+yQz64KuIMerGA4jn0cEu+E4j i6K77oRsJ4JVrJvF4ShIzTeHeccs76gdH4nReE7A4lDyNI5VJVrw/dFONj2k1AHj62Rh Jp1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690841434; x=1691446234; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=DlAyd4Q7B78yLvEJKP2mUg3Nc7x+jQgLb2BqzOZvnGk=; b=YqT4X1zpPEqzxPI0bfE3vj8QAm4n41nvcN9h+pnSCOe8AxcpXZKjN/7JhunDo7xgtg +Xq8ry/h64zkvthPJ5uLeycddNXgDuUzAaZL0ZLwR1TJGLKkD5a4YutqpGjr+srjvwgH mwb2V2Ezd300XikJB18fskFkyzchIBSfJ8RSKhrfjSQ8MYqYIUKzUGndJzDXyO0LW0OL eqZN0kbFNh3w6+h8LZbUr+bnpm+3AGbaVhPbcF8b8HRCn6v23vgRR7blRDr+sVo5PwbP 3Z9stcA1JQMFT9vlLGb2cfoNQtdeXF3q2kg/f4vnfLcWOPgtKey2+9BD6+TM7miSq+yj tzGQ== X-Gm-Message-State: ABy/qLY559axaAEctKglZPCd5AN/oR8w0pns4hT5m2Rt8AK5z7U8wsws s4bHWfj/30AGYQt8wfQGBggH+w== X-Google-Smtp-Source: APBJJlFK6mg6nlqkCKECMzzasB8UQVZgao/mRv1XJMrTb/q/W/sh1tnHJQw74hQVwKy8oDA9EEO8BQ== X-Received: by 2002:a05:6a20:8f15:b0:11e:7ced:3391 with SMTP id b21-20020a056a208f1500b0011e7ced3391mr12428050pzk.43.1690841434666; Mon, 31 Jul 2023 15:10:34 -0700 (PDT) Received: from jeff-laptop.lan (c-73-170-46-202.hsd1.ca.comcast.net. [73.170.46.202]) by smtp.gmail.com with ESMTPSA id 18-20020aa79152000000b00686f0b15b06sm7988646pfi.188.2023.07.31.15.10.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Jul 2023 15:10:34 -0700 (PDT) Message-ID: Subject: Re: pgsql: Fix search_path to a safe value during maintenance operations. From: Jeff Davis To: Robert Haas Cc: Tom Lane , Noah Misch , "pgsql-hackers@postgresql.org" , Nathan Bossart Date: Mon, 31 Jul 2023 15:10:32 -0700 In-Reply-To: References: <89a415b86d5421941e4281ba5bf6288934078624.camel@j-davis.com> <573014.1686375211@sss.pgh.pa.us> <20230612170510.GA201972@gust.leadboat.com> <20230613182920.GA259321@gust.leadboat.com> <1799839.1686687804@sss.pgh.pa.us> <4df537f5a0d8c0ceac3eec3809d1144880b8e76d.camel@j-davis.com> <578fb4be80247570e6a05924908765a0b345971e.camel@j-davis.com> <43bbc9f7318057f51552d5986830908cb018dadf.camel@j-davis.com> <1659699.1688086436@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2023-07-31 at 12:53 -0400, Robert Haas wrote: > I agree. I think there are actually two interrelated problems here. >=20 > One is that virtually all code needs to run with the originally > intended search_path rather than some search_path chosen at another > time and maybe by a different user. If not, it's going to break, or > compromise security, depending on the situation. The other is that > running arbitrary code written by somebody else as yourself is > basically instant death, from a security perspective. Good framing. The search_path is a particularly nasty problem in our system because it means that users can't even trust the code that they write themselves! A function author has no way to know how their own function will behave under a different search_path. > It's a little hard to imagine a world in which these problems don't > exist at all, but it somehow feels like the design of the system > pushes you toward doing this stuff incorrectly rather than doing it > correctly. For instance, you can imagine a system where when you run > CREATE OR REPLACE FUNCTION, the prevailing search_path is captured > and > automatically included in proconfig. Capturing the environment is not ideal either, in my opinion. It makes it easy to carelessly depend on a schema that others might not have USAGE privileges on, which would then create a runtime problem for other callers. Also, I don't think we could just depend on the raw search_path, we'd need to do some processing for $user, and there are probably a few other annoyances. It's one possibility and we don't have a lot of great options, so I don't want to rule it out though. If nothing else it could be a transition path to something better. > But you can maybe imagine a system where > all code associated with a table is run as the table owner in all > cases, regardless of SECURITY INVOKER/DEFINER, which I think would at > least close some holes. >=20 > The difficulty is that it's a bit hard to imagine making these kinds > of definitional changes now, because they'd probably be breaking > changes for pretty significant numbers of users. I believe we can get close to a good model with minimal breakage. And when we make the problem small enough I believe other solutions will emerge. We will probably have to hedge with some compatibility GUCs. > But on the other > hand, if we don't start thinking about systemic changes here, it > feels > like we're just playing whack-a-mole. Exactly. If we can agree on where we're going then I think we can get there. Regards, Jeff Davis