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..
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.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
