Thread: [BUGS] BUG #14872: libpq requires a home directory
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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
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