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 1mmj8y-0006gU-OA for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Nov 2021 21:04:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mmj8x-00043F-OD for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Nov 2021 21:03: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 1mmj8x-000436-Ep for pgsql-hackers@lists.postgresql.org; Mon, 15 Nov 2021 21:03:59 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mmj8u-0000Xy-WB for pgsql-hackers@lists.postgresql.org; Mon, 15 Nov 2021 21:03:59 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1AFL3rZD2152989; Mon, 15 Nov 2021 16:03:53 -0500 From: Tom Lane To: "Bossart, Nathan" cc: "pgsql-hackers@lists.postgresql.org" Subject: Re: Improving psql's \password command In-reply-to: <5EDA38EF-C411-4C7D-A9BC-10B1D4584E5E@amazon.com> References: <747443.1635536754@sss.pgh.pa.us> <765509.1635552418@sss.pgh.pa.us> <7BAC8A28-148B-4B03-A345-D68071388300@amazon.com> <1553329.1636647111@sss.pgh.pa.us> <1847699.1636747076@sss.pgh.pa.us> <2141902.1636999964@sss.pgh.pa.us> <5EDA38EF-C411-4C7D-A9BC-10B1D4584E5E@amazon.com> Comments: In-reply-to "Bossart, Nathan" message dated "Mon, 15 Nov 2021 20:30:49 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2152987.1637010233.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Nov 2021 16:03:53 -0500 Message-ID: <2152988.1637010233@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Bossart, Nathan" writes: > On 11/15/21, 10:13 AM, "Tom Lane" wrote: >> * I don't believe that this bit is necessary, or if it is, >> the comment fails to justify it: >> = >> - initStringInfo(&buf); >> + /* make sure buf is palloc'd so we don't lose changes after a l= ongjmp */ >> + buf =3D makeStringInfo(); > My main worry was that buf->data might get repalloc'd via > enlargeStringInfo(), which could cause problems after a longjmp. So what? That has nothing to do with whether the buf struct itself is alloc'd or not. Besides which, no longjmp is going to happen during any reallocation. I'm not entirely sure what scenario you're worried about, but I don't see how alloc'ing the StringInfoData struct would make it any safer. If anything it'd be less safe, since the StringInfoData is certain to be on the stack, while a buf pointer variable is likely to be kept in a register. But really that doesn't matter anyhow, since this is a stack level below where the sigsetjmp call is. AFAIK the only longjmp clobber risk is to pg_get_line_append's mutable local variables, of which there are none. regards, tom lane