From: Tom Lane <tgl@sss.pgh.pa.us>
To: dcwatson@gmail.com
cc: pgsql-bugs@postgresql.org
Subject: Re: BUG #14872: libpq requires a home directory
In-reply-to: <20171025200457.1471.34504@wrigleys.postgresql.org>
References: <20171025200457.1471.34504@wrigleys.postgresql.org>
Comments: In-reply-to dcwatson@gmail.com
	message dated "Wed, 25 Oct 2017 20:04:57 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26002.1508967614.1@sss.pgh.pa.us>
Date: Wed, 25 Oct 2017 17:40:14 -0400
Message-ID: <26003.1508967614@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

dcwatson@gmail.com writes:
> It seems a side effect of allowing a pgpass file to be specified in libpq
> connections[1] is that libpq errors out if a home directory cannot be found.
> I'm building docker images for OpenShift which run as unnamed users without
> a home directory, and since upgrading to the latest psycopg2 (which is built
> against libpq 10), I get an error saying "Could not get home directory to
> locate password file".

Sigh.  We keep breaking that use-case... which is unsurprising because
nobody tests it.

According to previous go-rounds, eg commits 5b4067798 and bd58d9d88,
we should just silently do nothing if we can't get the home directory.

Poking around, it looks like parseServiceInfo's search for
~/.pg_service.conf has the same disease, but that code's been like that
since 2010 --- I wonder why it's not causing you problems?  Are you maybe
setting PGSERVICEFILE to prevent that from failing?

			regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs