From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christoph Berg <cb(at)df7cb(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq 9.4 requires /etc/passwd? |
Date: | 2015-01-10 00:01:32 |
Message-ID: | 20150110000132.GE26812@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 9, 2015 at 06:42:19PM -0500, Tom Lane wrote:
> Christoph Berg <cb(at)df7cb(dot)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 <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-01-10 00:02:32 | Re: Transactions involving multiple postgres foreign servers |
Previous Message | Tom Lane | 2015-01-09 23:57:02 | Re: libpq 9.4 requires /etc/passwd? |