BUG #14872: libpq requires a home directory

On Wed, Oct 25, 2017 at 1:04 PM, <dcwatson@gmail.com> wrote:

​​
I get an error saying "Could not get home directory to
locate password file". I think I've traced it to the referenced commit, and
was hoping to get some confirmation that this was indeed an unintended side
effect.

[1]
https://github.com/postgres/postgres/commit/ba005f193d88a8404e81db3df223cf
689d64d75e

​I agree and point out that the doc part of that commit says: "​(No error
is reported if this file does not exist.)".

David J.

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

I wrote:

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?

Ah, looking closer, we don't reach that code unless you've specified a
service name (either as a connection parameter or through the PGSERVICE
environment variable). So it's not so surprising that nobody complained
about that case yet. But it's still wrong.

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

On Wed, Oct 25, 2017 at 2:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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

:(
And really that's quite a common configuration to have a user
dedicated to Postgres that has no actual home folder.

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

Yes, this should be skipped. fe-secure-openssl.c is actually doing the
correct thing.

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?

Yeah... I was halfway into hacking a patch for that but got drowned
into other things until I saw your message. Are you working on a
patch?
--
Michael

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

Michael Paquier <michael.paquier@gmail.com> writes:

On Wed, Oct 25, 2017 at 2:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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?

Yeah... I was halfway into hacking a patch for that but got drowned
into other things until I saw your message. Are you working on a
patch?

Yeah, I'm on it.

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

On Wed, Oct 25, 2017 at 3:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

On Wed, Oct 25, 2017 at 2:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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?

Yeah... I was halfway into hacking a patch for that but got drowned
into other things until I saw your message. Are you working on a
patch?

Yeah, I'm on it.

Okay, I'm dropping the ball then. Note: this has been fixed as db6986f.
--
Michael

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