Re: libpq 9.4 requires /etc/passwd?

On Fri, Jan 9, 2015 at 06:57:02PM -0500, Tom Lane wrote:
> I 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.
>
> Hmm ... actually, I'll bet it's not $HOME that's at issue, but the name
> of the user. Commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 turned
> failure of pg_fe_getauthname() into a hard connection failure, whereas
> previously it was harmless as long as the caller provided a username.
>
> I wonder if we shouldn't just revert that commit in toto. Yeah,
> identifying an out-of-memory error might be useful, but this cure
> seems a lot worse than the disease. What's more, this coding reports
> *any* pg_fe_getauthname failure as "out of memory", which is much worse
> than useless.
>
> Alternatively, maybe don't try to resolve username this way until
> we've found that the caller isn't providing any username.

Seems we both found it at the same time. Here is the thread were we
discussed it, and you were concerned about the memory allocation failure
too:

http://www.postgresql.org/message-id/flat/20140320154905(dot)GC7711(at)momjian(dot)us#20140320154905(dot)GC7711@momjian.us

In particular, it appears to me that if the strdup in pg_fe_getauthname
fails, we'll just let that pass without comment, which is inconsistent
with all the other out-of-memory cases in conninfo_add_defaults.
(I wonder whether any code downstream of this supposes that we always
have a value for the "user" option. It's a pretty safe bet that the
case is hardly ever tested.)

I have developed the attached patch which documents why the user name
lookup might fail, and sets the failure string to "". It preserves the
memory allocation failure behavior.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +