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.
> I encountered this issue on my mail host, where I use virtual users.
> When mail is delivered, parameters such as UID, home directory, etc. are
> retrieved using multiple queries against a Postgres DB.
> As soon as the virtual user's UID (which does not exist in any local
> password database) is determined, exim setuid()s to it. All further
> queries then fail with an error similar to this one:
> PGSQL connection failed: could not get home directory to locate client
> certificate files
> FATAL: no pg_hba.conf entry for host "1.2.3.4", user "exim4", database
> "fake_name", SSL off
> Looking at interfaces/libpq/fe-secure.c, it seems that such a failure
> previously only occurred when sslmode was "verify-*", otherwise the
> missing home dir was ignored. Now, it always fails.
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?
regards, tom lane
