Re: libpq 9.4 requires /etc/passwd?

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. +

In response to

Browse pgsql-hackers by date

  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?