On 03/04/2011 12:58 AM, Tom Lane wrote:
> I wrote:
>> Christian Kastner <debian@kvr.at> writes:
>>> Using libpq 9.0.3, when an SSL connection is attempted from a client
>>> whose EUID is not in a password database, the connection fails because
>>> the home directory cannot be determined. With libpq 8.4.7, everything is
>>> fine.
>
>> Hmm. Offhand I agree that that seems like an unnecessary regression.
>> It should act just the same as if it could not find any of those files.
>> A quick look with git blame suggests that this got broken in my
>> commit 4ed4b6c54e5fab24ab2624d80e26f7546edc88ad, and I don't think
>> that it was intentional.
>
>> One small problem is that if the sslmode is "verify-ca" or
>> "verify-full", failure to find the root cert file is an error,
>> and that error message normally includes the pathname at which
>> the cert file was sought. What shall we print if we couldn't
>> identify the home directory?
>
> Attached is an untested patch which I'd appreciate if you (or somebody
> else who uses SSL connections more than I do) could test.
I can confirm that this fixes the issue for me.
I tested this with psql and PGSSLMODE={disable,prefer,verify-ca}, with
various (or no) PGSSLROOTCERTs in the case of verify-ca. In all cases,
the result was the expected one.
> I resolved the last mentioned problem by printing
> "~/.postgresql/root.crt", which is a bit of a Unix-ism but doesn't
> seem too unreasonable, and anyway we weren't printing anything
> terribly useful before either. We could change that message though if
> we wanted, since AFAICS the only way to get there is
> pqGetHomeDirectory failure. So we could just print the "could not get
> home directory" message instead. Thoughts?
IMO your solution is fine. It clearly states that the certificate file
(at the default path) does not exist; whether this is because the file
itself or the home directory is missing appears to me as a trivial detail.
Thanks for the quick help!
Christian