Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iPLeL-0004y6-4P for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Oct 2019 07:10:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iPLeJ-0002fu-Py for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Oct 2019 07:10:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iPLeI-0002dW-Q7 for pgsql-hackers@lists.postgresql.org; Tue, 29 Oct 2019 07:10:39 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iPLeE-0005dI-OA for pgsql-hackers@postgresql.org; Tue, 29 Oct 2019 07:10:38 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id F2B0822076; Tue, 29 Oct 2019 03:10:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 29 Oct 2019 03:10:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=gM0GeKYOY9Lv8A3F2eZuPYCKqe/y8gDkHlhtJCJmV 3U=; b=W7QSGhhOqguo3OYgL2rm37YIxBQdQWaw/BHDrHJSXJbDUnYnq0/DgXLEZ LHp/KMDlLl7DyjCfgpG3WV6Cu/A33BFaH/ov3YwmTThkA7v+KRh/rNZm0AN1Nr0f 5IeAKvo/Uqj2DPDC/kVGFvgUOu81ofPLpZTMX9jtenhhDlGtI0qjSYot7w84TMzG 3t6AOkgPsakvhsvTiM3DC+LDiFMKVkXMsDgPi1yTPWPjzuV6S784oU3M+KUgTYmb o+z4cQAUXEd3TUGQGPWPu0fm9YowD5WgGqH302M+2VR+ny+C/04AyfMDT+2yPBip xa5FZbYODZa4KxjQSDM9MI7VMOErA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddttddguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhohfkffgfgggjtgfgse htjeertddtfeejnecuhfhrohhmpefrvghtvghrucfgihhsvghnthhrrghuthcuoehpvght vghrrdgvihhsvghnthhrrghuthesvdhnughquhgrughrrghnthdrtghomheqnecuffhomh grihhnpedvnhguqhhurggurhgrnhhtrdgtohhmnecukfhppeelfedrvdegvddrudegjedr jeelnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghuth esvdhnughquhgrughrrghnthdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from april.pezone.net (p5df2934f.dip0.t-ipconnect.de [93.242.147.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 082DBD60063; Tue, 29 Oct 2019 03:10:29 -0400 (EDT) Subject: Re: Remove one use of IDENT_USERNAME_MAX To: Tom Lane , Kyotaro Horiguchi References: <20191028.141008.1808344564081861818.horikyota.ntt@gmail.com> <14311.1572270354@sss.pgh.pa.us> Cc: pgsql-hackers@postgresql.org From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Tue, 29 Oct 2019 08:10:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <14311.1572270354@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-10-28 14:45, Tom Lane wrote: > Kyotaro Horiguchi writes: >> At Sat, 26 Oct 2019 08:55:03 +0200, Peter Eisentraut wrote in >>> IDENT_USERNAME_MAX is the maximum length of the information returned >>> by an ident server, per RFC 1413. Using it as the buffer size in peer >>> authentication is inappropriate. It was done here because of the >>> historical relationship between peer and ident authentication. But >>> since it's also completely useless code-wise, remove it. > >> In think one of the reasons for the coding is the fact that *pw is >> described to be placed in the static area, which can be overwritten by >> succeeding calls to getpw*() functions. > > Good point ... so maybe pstrdup instead of using a fixed-size buffer? Maybe. Or we just decide that check_usermap() is not allowed to call getpw*(). It's just a string-matching routine, so it doesn't have any such business anyway. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services