2010/1/24 Magnus Hagander <magnus(at)hagander(dot)net>:
> 2010/1/20 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> As Tom pointed out, it is fundamentally same.
>> The matter is this random() invocation is the first time after
>> initialization of random seed by srandom(). It means an external observer
>> can estimate the random value uniquely using pid and startup time.
>> In other representation, the "random" value is the result of function
>> which takes arguments of pid and startup time, without random factor.
>> for (i = 0; i< RADIUS_VECTOR_LENGTH; i++)
>> packet->vector[i] = f(getpid(), port->SessionStartTime, i);
>> One idea is to modify the logic to set up random seed in BackendRun().
>> In most of UNIX-like operating system, we can use /dev/random as a random
>> seed which is well randomized.
>> It seems to me PostmasterRandom() is a right place to set random seed,
>> and we can inject a block something like #ifdef HAVE_DEV_RANDOM ...
>> Instead of such kind of efforts, we can also document that PostgreSQL and
>> RADIUS server should have communication using enough secure connection
>> explicitly. IMO, it will cover most of use cases.
> There is one more option here - use OpenSSL if available. It has
> functions for secure random number generations
> (http://www.openssl.org/docs/crypto/RAND_bytes.html). That seems easy
> enough when OpenSSL is available.
> The question then becomes what do we do if we don't have OpenSSL
> available? Do we document that it's not secure, or refuse to run it?
> I'd vote for document it.. If you don't have SSL enabled, then you
> clearly don't use SSL for the libpq connection, which means the
> password goes in cleartext in that stream...
Updated patch attached.
Description: application/octet-stream (19.5 KB)
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2010-01-24 16:00:06|
|Subject: Re: handling contrib directories as modules not shared
|Previous:||From: Teodor Sigaev||Date: 2010-01-24 15:55:04|
|Subject: Re: Red-black tree for GIN|