* 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. Thanks! Stephen
signature.asc
Description: Digital signature