On Fri, Mar 4, 2011 at 00:58, Tom Lane <tgl@sss.pgh.pa.us> 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. =A0Offhand 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. =A0What 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. =A0I 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. =A0We could
> change that message though if we wanted, since AFAICS the only way to
> get there is pqGetHomeDirectory failure. =A0So we could just print the
> "could not get home directory" message instead. =A0Thoughts?
Is there any case when it would actually be realistic that we don't
find the home directory, but the user can't figure out that's why it
couldn't find the file? If so, the "could not get home directory" adds
some more information... We can't exactly expect the end user to know
that this is the only codepath that can lead to the error message...
--=20
=A0Magnus Hagander
=A0Me: http://www.hagander.net/
=A0Work: http://www.redpill-linpro.com/
