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 1og4X3-0006LD-NP for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Oct 2022 13:33:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1og4X2-0007Rc-Dt for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Oct 2022 13:33:52 +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 1og4X2-0007RS-46 for pgsql-hackers@lists.postgresql.org; Wed, 05 Oct 2022 13:33:52 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1og4Wz-0005KR-Rl for pgsql-hackers@postgresql.org; Wed, 05 Oct 2022 13:33:51 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 66A0F5C010F; Wed, 5 Oct 2022 09:33:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 05 Oct 2022 09:33:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664976828; x= 1665063228; bh=vPjx8E8KrebYIetbJTCJcOH2OPzAIJvKkPFlYtB8BkY=; b=C 6p4o4SSo6FyZE8iY6++Z0bU88koIJ8xA5QJwPxOQGlRMJ15W4QrC+Sdm0vpDo6yf DhvsdG6q8lipZgz8AVooYPicHeeOHBUQvXDvgxlTMGZymG1UfQJeMgKjcu3uBBUr Na+vbUbpNt/nTYHpd0GF+F6u+ukOztpi50vRta0XywJg0+41Crq3KCOIZ+3QqDN8 F3n6u1+T+W+B6iJhYFVR6S7DL3ckY6DyI6UNwYeWxyZCF+X+UUyewOiRfyGnyoEZ 1sEqHHfwbwOqxcVNMgl1PRTJIVlq2jTBz8CQozKXOkGjp7R0aoBkZjkqplmCueOL cnPh3GXDZGfvOsXS7ZjTQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeifedgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvghnth gvrhhprhhishgvuggsrdgtohhmqeenucggtffrrghtthgvrhhnpeehleffgeegudejteei hfelteduvdeifffhffdvjedvffegjeekudeludehudeifeenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghu thesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Oct 2022 09:33:47 -0400 (EDT) Message-ID: <8e2e5fb6-8225-de8a-b0f9-178c27402367@enterprisedb.com> Date: Wed, 5 Oct 2022 15:33:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PoC] Let libpq reject unexpected authentication requests Content-Language: en-US To: Jacob Champion Cc: "pgsql-hackers@postgresql.org" , Michael Paquier , "David G. Johnston" References: <9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com> <77358b4c-6497-e5d3-c13c-57522654af25@enterprisedb.com> <914a0125-3dfb-920f-51b6-8d44a8edbdd2@enterprisedb.com> <949f1c20-771c-aef7-058f-2c10885db955@enterprisedb.com> From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 23.09.22 02:02, Jacob Champion wrote: > On Thu, Sep 22, 2022 at 4:52 AM Peter Eisentraut > wrote: >> On 22.09.22 01:37, Jacob Champion wrote: >>> I think this is potentially >>> dangerous, but it mirrors the current behavior of libpq and I'm not >>> sure that we should change it as part of this patch. >> >> It might be worth reviewing that behavior for other reasons, but I think >> semantics of your patch are correct. > > Sounds good. v9 removes the TODO and adds a better explanation. I'm generally okay with these patches now. > I'm not able to test SSPI easily at the moment; if anyone is able to > try it out, that'd be really helpful. There's also the question of > SASL forwards compatibility -- if someone adds a new SASL mechanism, > the code will treat it like scram-sha-256 until it's changed, and > there will be no test to catch it. Should we leave that to the future > mechanism implementer to fix, or add a mechanism check now so the > client is safe even if they forget? I think it would be good to put some provisions in place here, even if they are elementary. Otherwise, there will be a significant burden on the person who implements the next SASL method (i.e., you ;-) ) to figure that out then. I think you could just stick a string list of allowed SASL methods into PGconn. By the way, I'm not sure all the bit fiddling is really worth it. An array of integers (or unsigned char or whatever) would work just as well. Especially if you are going to have a string list for SASL anyway. You're not really saving any bits or bytes either way in the normal case. Minor comments: Pasting together error messages like with auth_description() isn't going to work. You either need to expand the whole message in check_expected_areq(), or perhaps rephrase the message like libpq_gettext("auth method \"%s\" required, but server requested \"%s\"\n"), conn->require_auth, auth_description(areq) and make auth_description() just return a single word not subject to translation. spurious whitespace change in fe-secure-openssl.c whitespace error in patch: .git/rebase-apply/patch:109: tab in indent. via TLS, nor GSS authentication via its encrypted transport.) In the 0002 patch, the configure test needs to be added to meson.build.