On Fri, Jan 9, 2015 at 06:42:19PM -0500, Tom Lane wrote:
> Christoph Berg <cb@df7cb.de> writes:
> > libpq wants the user home directory to find .pgpass and
> > .pg_service.conf files, but apparently the behavior to require the
> > existence of the passwd file (or nss equivalent) is new in 9.4.
>
> There is demonstrably no direct reference to /etc/passwd in the PG code.
> It's possible that we've added some new expectation that $HOME can be
> identified, but a quick look through the code shows no such checks that
> don't look like they've been there for some time.
>
> Are the complainants doing anything that would result in SSL certificate
> checking? More generally, it'd be useful to see an exact example of
> what are the connection parameters and environment that result in a
> failure.
I see similar error strings, but nothing that ends with a question mark:
"out of memory?". However, I wonder if the crux of the problem is that
they are running in a chroot environment where the user id can't be
looked up.
Looking at libpq's pg_fe_getauthname(), I see that if it can't get the
OS user name of the effective user, it assumes it failed and returns
NULL:
/* * We document PQconndefaults() to return NULL for a memory allocation * failure. We don't have an API
toreturn a user name lookup failure, so * we just assume it always succeeds. */#ifdef WIN32 if
(GetUserName(username,&namesize)) name = username;#else if (pqGetpwuid(geteuid(), &pwdstr, pwdbuf,
sizeof(pwdbuf),&pw) == 0) name = pw->pw_name;#endif authn = name ? strdup(name) : NULL;
and conninfo_add_defaults() assumes a pg_fe_getauthname() failure is a
memory allocation failure:
option->val = pg_fe_getauthname();if (!option->val){ if (errorMessage) printfPQExpBuffer(errorMessage,
libpq_gettext("out of memory\n")); return false;
It was my 9.4 commit that changed this:
commit a4c8f14364c27508233f8a31ac4b10a4c90235a9Author: Bruce Momjian <bruce@momjian.us>Date: Thu Mar 20 11:48:31 2014
-0400 libpq: pass a memory allocation failure error up to PQconndefaults() Previously user name memory allocation
failureswere ignored and the default user name set to NULL.
I am thinking we have to now assume that user name lookups can fail for
other reasons. I am unclear how this worked in the past though.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +