Horton

Thread

Commits

  1. Fix libpq to not require user's home directory to exist.

  2. Allow password file name to be specified as a libpq connection parameter.

  1. BUG #14872: libpq requires a home directory

    dcwatson@gmail.com — 2017-10-25T20:04:57Z

    The following bug has been logged on the website:

Bug reference:      14872
Logged by:          Dan Watson
Email address:      dcwatson@gmail.com
PostgreSQL version: 10.0
Operating system:   Linux
Description:        

Hello,

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". 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. Seems like the absence of a home directory should not be an error
condition, just don't look for pgpass in the default location in that
case.

Regards,
Dan

[1]
https://github.com/postgres/postgres/commit/ba005f193d88a8404e81db3df223cf689d64d75e

  2. Re: BUG #14872: libpq requires a home directory

    David G. Johnston <david.g.johnston@gmail.com> — 2017-10-25T21:37:03Z

    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.

  3. Re: BUG #14872: libpq requires a home directory

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-10-25T21:40:14Z

    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

  4. Re: BUG #14872: libpq requires a home directory

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-10-25T22:10:36Z

    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

  5. Re: BUG #14872: libpq requires a home directory

    Michael Paquier <michael.paquier@gmail.com> — 2017-10-25T22:35:17Z

    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

  6. Re: BUG #14872: libpq requires a home directory

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-10-25T22:40:20Z

    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

  7. Re: BUG #14872: libpq requires a home directory

    Michael Paquier <michael.paquier@gmail.com> — 2017-10-26T05:20:06Z

    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