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 1gcbPo-0003g6-FR for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Dec 2018 19:33:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gcbPn-0002cA-1o for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Dec 2018 19:33:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gcbPm-0002ZF-MB for pgsql-hackers@lists.postgresql.org; Thu, 27 Dec 2018 19:33:54 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gcbPk-00052o-5e for pgsql-hackers@postgresql.org; Thu, 27 Dec 2018 19:33:53 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id wBRJXYE3009586; Thu, 27 Dec 2018 14:33:35 -0500 From: Tom Lane To: Peter Geoghegan cc: Michael Paquier , Alvaro Herrera , Adrien Nayrat , Thomas Munro , Dmitry Dolgov <9erthalion6@gmail.com>, Tomas Vondra , Vik Fearing , Robert Haas , David Rowley , Pg Hackers Subject: Re: random() (was Re: New GUC to sample log queries) In-reply-to: References: <20181129214850.kiq6mvofsgplqjdr@alvherre.pgsql> <3859.1545849900@sss.pgh.pa.us> <20181227013458.GF2106@paquier.xyz> <32696.1545875185@sss.pgh.pa.us> <2820.1545878340@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Wed, 26 Dec 2018 18:55:08 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9584.1545939214.1@sss.pgh.pa.us> Date: Thu, 27 Dec 2018 14:33:34 -0500 Message-ID: <9585.1545939214@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Geoghegan writes: > On Wed, Dec 26, 2018 at 6:39 PM Tom Lane wrote: >> Now, we could probably fix that with some less intrusive patch than >> #define'ing random() --- in particular, if we give drandom and setseed >> their own private PRNG state, we've really fixed the security exposure >> without need to change anything else anywhere. So maybe we should >> just do that and be happy. > +1. I don't like the idea of #define'ing random() myself. > We're already making fairly broad assumptions about our having control > of the backend's PRNG state within InitProcessGlobals(). How should > this affect the new drandom()/setseed() private state, if at all? I would think that InitProcessGlobals would initialize drandom's seed alongside random()'s seed. Hopefully to values not easily predictable from each other -- see also Munro's comment, which I'll respond to in a moment. regards, tom lane