* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 10/17/2016 05:50 PM, Tom Lane wrote:
> >Heikki Linnakangas <heikki.linnakan...@iki.fi> writes:
> >>Replace PostmasterRandom() with a stronger way of generating randomness.
> >
> >This patch broke padmeleon:
> >
> >016-10-17 09:57:17.782 EDT [5804d8bd.57c2:1] LOG:  database system was shut 
> >down at 2016-10-17 09:57:17 EDT
> >2016-10-17 09:57:17.790 EDT [5804d8bd.57c2:2] LOG:  MultiXact member 
> >wraparound protections are now enabled
> >2016-10-17 09:57:17.807 EDT [5804d8bd.57c6:1] LOG:  autovacuum launcher 
> >started
> >2016-10-17 09:57:17.820 EDT [5804d8bd.57bf:1] LOG:  database system is ready 
> >to accept connections
> >2016-10-17 09:57:18.516 EDT [5804d8bd.57bf:2] LOG:  could not generate 
> >random query cancel key
> >2016-10-17 09:57:19.544 EDT [5804d8bd.57bf:3] LOG:  could not generate 
> >random query cancel key
> >2016-10-17 09:57:20.563 EDT [5804d8bd.57bf:4] LOG:  could not generate 
> >random query cancel key
> >2016-10-17 09:57:21.584 EDT [5804d8bd.57bf:5] LOG:  could not generate 
> >random query cancel key
> >2016-10-17 09:57:22.604 EDT [5804d8bd.57bf:6] LOG:  could not generate 
> >random query cancel key
> >
> >It's failing because this machine lacks /dev/random and /dev/urandom.
> >It does have a non-kernel entropy daemon (prngd), which OpenSSL knows how
> >to read from but the hard-wired code in pg_strong_random() does not.
> >
> >I'm not sure whether it's worth trying to make pg_strong_random() aware
> >of prngd.
> Seems simple enough..

If it is, then that's certainly tempting, especially if that's the only
platform we support where we don't have a better option, and we wish to
continue supporting it.

> > The real issue here is whether we are willing to say that
> >Postgres simply does not work anymore on machines without standard entropy
> >sources.  Doesn't matter whether the user cares about the strength of
> >cancel keys, we're just blowing them off.  That seems a bit extreme
> >from here.  I think we should be willing to fall back to the old code
> >if we can't find a real entropy source.
> I'm scared of having pg_strong_random() that is willing to fall back
> to not-so-strong values. We can rename it, of course, but it seems
> dangerous to use a weak random-number generator for authentication
> purposes (query cancel, MD5 salts, SCRAM nonces).
> I think both for the MD5 salt and SCRAM, it doesn't have to be
> unpredictable to attackers, as long the attacker cannot influence it
> so that a particular value is chosen. For query cancel, it needs to
> be unpredictable, but the query cancel key is quite short anyway,
> and we haven't worried about it so far anyway, because an attacker
> can't do very much damage by just canceling queries.
> One option would be to disable query-canceling and MD5 (and SCRAM)
> authentication, if we don't have an entropy source.

Wouldn't it be possible to make this a build-time question..?  I don't
particularly like the idea of pg_strong_random() falling back to
not-strong values, but maybe we could have a '--use-weak-random'
configure switch for platforms that don't provide a strong source.

Then again, if we wish to support this platform, then perhaps we should
put in the effort to support prngd.



Attachment: signature.asc
Description: Digital signature

Reply via email to