On Tue, Sep 20, 2016 at 12:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Yeah, random() is the wrong thing. It should use PostmasterRandom(). >> Fixed to do that instead. > > I am not very happy about this patch; have you considered the security > implications of what you just did?
Hmm. No. > If you haven't, I'll tell you: > you just made the postmaster's selection of "random" cancel keys and > password salts a lot more predictable. Formerly, the srandom() seed > for those depended on both the postmaster start time and the time of > the first connection request, but this change removes the first > connection request from the equation. If you know the postmaster start > time --- which we will happily tell any asker --- it will not take too > many trials to find the seed that's in use. Realistically, in some large percentage of the real-world installs, that's not going to take too many trials anyway. People don't generally start a postmaster so that they can NOT connect to it, and there are plenty of real-world installations where you can count on the first connection happening in well under 1s. I'd suggest that if you're relying on that time being a secret for anything very security-critical, you're already in trouble. > I'd be the first to agree that this point is inadequately documented > in the code, but PostmasterRandom should be reserved for its existing > security-related uses, not exposed to the world for (ahem) random other > uses. So, we could have dsm_postmaster_startup() seed the random number generator itself, and then let PostmasterRandom() override the seed later. Like maybe: struct timeval tv; gettimeofday(&tv, NULL); srandom(tv.tv_sec); ... dsm_control_handle = random(); dsm_postmaster_startup() doesn't care very much about whether an adversary can predict the chosen DSM control segment ID, but it doesn't want to keep picking the same one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
