Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] - Mailing list pgsql-bugs

From Thomas Munro
Subject Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local]
Date
Msg-id CAEepm=094tcbtyXdqtTHZ8NO0FFzrUZZ-i=h5XJ4rrEYvAaWGQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local]  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local]  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-bugs
On Tue, Nov 27, 2018 at 3:02 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 25/11/2018 23:30, Thomas Munro wrote:
> >>> I wonder if anyone out there has come to rely on the value "[local]"
> >> I vote for changing it, and documenting it in the release notes.
> > Yeah.  Here is a draft patch to change that.  Test output:
> >
> > $ psql -h localhost postgres munro
> > PAM_USER=munro, PAM_RHOST=localhost
> > $ psql postgres munro
> > PAM_USER=munro, PAM_RHOST=
>
> I think this is the right thing to do.
>
> About your patch, if we're not going to set PAM_RHOST, then we should
> also avoid the call to pg_getnameinfo_all() earlier in CheckPAMAuth().
> Look at the original patch linked earlier in the thread; we just need to
> put if statements around both of those hunks.

Thanks for the review.  Right.  Here's a new version that moves both
things under the same if, and refactors a long line to fit in passing.

I wondered whether we could write
src/test/authentication/t/003_pam.pl, but it seems hard to do without
underhand tricks.  Both open source PAM implementations really want to
read their configuration from /etc.

-- 
Thomas Munro
http://www.enterprisedb.com

Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15522: pg_upgrade from 9.6 to PG 11.1 with postgis 2.4.5 giveerror undefined symbol geod_polygon_init
Next
From: Peter Geoghegan
Date:
Subject: Re: New sessions on a database to be dropped consume 100% cpu