On Fri, Jan 9, 2015 at 06:42:19PM -0500, Tom Lane wrote:
> Christoph Berg <c...@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 to return 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 a4c8f14364c27508233f8a31ac4b10a4c90235a9
Author: Bruce Momjian <br...@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 failures were 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 <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
