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?
> 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
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;
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.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: