From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
cc: Peter Geoghegan <pg@bowt.ie>, Michael Paquier <michael@paquier.xyz>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Adrien Nayrat <adrien.nayrat@anayrat.info>,
        Dmitry Dolgov <9erthalion6@gmail.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Vik Fearing <vik.fearing@2ndquadrant.com>,
        Robert Haas <robertmhaas@gmail.com>,
        David Rowley <david.rowley@2ndquadrant.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: random() (was Re: New GUC to sample log queries)
In-reply-to: 
 <CAEepm=1tJB2=w_GdXHRLkWQcCnFWGdmNiEdd5rupShKT=DwWyQ@mail.gmail.com>
References: <20181129214850.kiq6mvofsgplqjdr@alvherre.pgsql>
 <3859.1545849900@sss.pgh.pa.us> <20181227013458.GF2106@paquier.xyz>
 <32696.1545875185@sss.pgh.pa.us>
 <CAH2-Wz=xJiy+BgU7M49L6EHSkMbJWbzbprge=AqyOC8aDXRj8A@mail.gmail.com>
 <2820.1545878340@sss.pgh.pa.us>
 <CAH2-WznuXsWmjnvbt=odKMVxpj1zutgzRb7s6Vu3VPXCjejS5g@mail.gmail.com>
 <CAEepm=1tJB2=w_GdXHRLkWQcCnFWGdmNiEdd5rupShKT=DwWyQ@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@enterprisedb.com>
	message dated "Thu, 27 Dec 2018 17:55:16 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9702.1545939393.1@sss.pgh.pa.us>
Date: Thu, 27 Dec 2018 14:36:33 -0500
Message-ID: <9703.1545939393@sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Thu, Dec 27, 2018 at 3:55 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> On Wed, Dec 26, 2018 at 6:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> The point here is not to be cryptographically strong at every single
>>> place where the backend might want a random number; I think we're
>>> all agreed that we don't need that.  To me, the point is to ensure that
>>> the user-accessible random sequence is kept separate from internal uses,
>>> and the potential security exposure in the new random-logging patch is
>>> what justifies getting more worried about this than we were before.

> +1, but I wonder if just separating them is enough.  Is our seeding
> algorithm good enough for this new purpose?  The initial seed is 100%
> predictable to a logged in user (it's made from the backend PID and
> backend start time, which we tell you), and not even that hard to
> guess from the outside, so I think Coverity's warning is an
> understatement in this case.  Even if we separate the PRNG state used
> for internal stuff so that users can't clobber its seed from SQL,
> wouldn't it be possible to predict which statements will survive the
> log sampling filter given easily available information and a good
> guess at how many times random() (or whatever similar thing) has been
> called so far?

Yeah, that's a good point.  Maybe we should upgrade the per-process
seed initialization to make it less predictable.  I could see expending
a call of the strong RNG to contribute some more noise to the seeds
selected in InitProcessGlobals().

			regards, tom lane