pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
8+ messages / 4 participants
[nested] [flat]
* BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
@ 2018-11-24 10:45 PG Bug reporting form <noreply@postgresql.org>
2018-11-24 11:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
0 siblings, 1 reply; 8+ messages in thread
From: PG Bug reporting form @ 2018-11-24 10:45 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: albert_schabhuetl@yahoo.de
The following bug has been logged on the website:
Bug reference: 15520
Logged by: Albert Schabhuetl
Email address: albert_schabhuetl@yahoo.de
PostgreSQL version: 10.4
Operating system: RHEL 7.4
Description:
When PAM authentication is configured for local connections via domain
socket,
during authentication the backend process sends out a DNS query
for the following symbolic hostname: [local]
This is unnecessary as it is not intended that this hostname will ever
resolve to a valid IP address,
and depending on how DNS queries are answered in the actual system it can
cause authentication delays.
Theory why this happens:
Since this commit
https://github.com/postgres/postgres/commit/2f1d2b7a75fecad25295cb3f453503eb6a176d4f#diff-f5a9c53142...
during PAM authenticaion the functions
pg_getnameinfo_all
pam_set_item
are called, in order to support the PAM configuration option
"pam_use_hostname".
In the case of a TCP connection and pam_use_hostname = 0,
pg_getnameinfo_all still calls the library function
getnameinfo
but with flags = 0 to achieve "do nothing" behaviour.
In the case of a domain socket connection,
regardless of pam_use_hostname,
pg_getnameinfo_all calls
getnameinfo_unix,
which ignores the flags parameter and invariably
sets the hostname to a symbolic text - [local] in our case.
When subsequently the PAM library function
pam_set_item
is called, it gets the symbolic hostname [local]
and probably it is this function which sends the DNS request for this
hostname.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
2018-11-24 10:45 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] PG Bug reporting form <noreply@postgresql.org>
@ 2018-11-24 11:57 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-24 21:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Munro @ 2018-11-24 11:57 UTC (permalink / raw)
To: albert_schabhuetl@yahoo.de, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Sat, Nov 24, 2018 at 11:46 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 15520
> Logged by: Albert Schabhuetl
> Email address: albert_schabhuetl@yahoo.de
> PostgreSQL version: 10.4
> Operating system: RHEL 7.4
> Description:
>
> When PAM authentication is configured for local connections via domain
> socket,
> during authentication the backend process sends out a DNS query
> for the following symbolic hostname: [local]
>
> This is unnecessary as it is not intended that this hostname will ever
> resolve to a valid IP address,
> and depending on how DNS queries are answered in the actual system it can
> cause authentication delays.
>
> Theory why this happens:
>
> Since this commit
> https://github.com/postgres/postgres/commit/2f1d2b7a75fecad25295cb3f453503eb6a176d4f#diff-f5a9c53142...
> during PAM authenticaion the functions
> pg_getnameinfo_all
> pam_set_item
> are called, in order to support the PAM configuration option
> "pam_use_hostname".
>
> In the case of a TCP connection and pam_use_hostname = 0,
> pg_getnameinfo_all still calls the library function
> getnameinfo
> but with flags = 0 to achieve "do nothing" behaviour.
>
> In the case of a domain socket connection,
> regardless of pam_use_hostname,
> pg_getnameinfo_all calls
> getnameinfo_unix,
> which ignores the flags parameter and invariably
> sets the hostname to a symbolic text - [local] in our case.
>
> When subsequently the PAM library function
> pam_set_item
> is called, it gets the symbolic hostname [local]
> and probably it is this function which sends the DNS request for this
> hostname.
Right, with a debugger I could see Linux PAM calling libaudit.so code
that tries to resolve the hostname:
#0 __GI_getaddrinfo (name=0x55b97d269d80 "[local]", service=0x0,
hints=0x7ffee7011730, pai=0x7ffee7011728) at
../sysdeps/posix/getaddrinfo.c:2295
#1 0x00007f5f4038822a in ?? () from /lib/x86_64-linux-gnu/libaudit.so.1
#2 0x00007f5f40388bb1 in audit_log_acct_message () from
/lib/x86_64-linux-gnu/libaudit.so.1
#3 0x00007f5f41060410 in ?? () from /lib/x86_64-linux-gnu/libpam.so.0
#4 0x00007f5f41060555 in ?? () from /lib/x86_64-linux-gnu/libpam.so.0
#5 0x000055b97b07d29b in CheckPAMAuth (password=0x55b97b4ae7fe "",
user=0x55b97d1d8fd8 "munro", port=0x55b97d1ff590) at auth.c:2249
It seems we shouldn't be passing a bogus hostname in PAM_RHOST.
--
Thomas Munro
http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
2018-11-24 10:45 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] PG Bug reporting form <noreply@postgresql.org>
2018-11-24 11:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
@ 2018-11-24 21:57 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-25 20:09 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Albert Schabhuetl <albert_schabhuetl@yahoo.de>
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Munro @ 2018-11-24 21:57 UTC (permalink / raw)
To: albert_schabhuetl@yahoo.de, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Sun, Nov 25, 2018 at 12:57 AM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> It seems we shouldn't be passing a bogus hostname in PAM_RHOST.
I wonder if we should simply not set PAM_RHOST for Unix sockets, since
(in the words of the Linux PAM man page) "[i]n some applications,
PAM_RHOST may be NULL", or set it to the hostname of the local
machine, since in a general sense it is "the hostname of the machine
from which the PAM_RUSER entity is requesting service" (Linux PAM) and
"[t]he name of the applicant's host" (OpenPAM). The latter doesn't
seem great because it means that a PAM module loses the ability to
distinguish this case from the IP case, so I think the former is
probably better. I haven't managed to find anything explicit about
the expected value of PAM_RHOST for Unix sockets in either the Linux
PAM or OpenPAM projects.
I wonder if anyone out there has come to rely on the value "[local]"
that PostgreSQL generates for this case (ie in a custom PAM module or
script executed with pam_exec.so), and would get upset if we changed
it. Seems pretty unlikely.
The comments for pg_getnameinfo_all() could probably do with a mention
of the special value written to "node" for Unix sockets.
Some relevant code:
We can see that linux-audit only starts trying to resolve host if you
didn't also pass in an address:
https://github.com/linux-audit/audit-userspace/blob/e42602b7b246ae62e7a12e9cd91f0ac37b1b1968/lib/aud...
We can also see that linux-pam always passes NULL as an address:
https://github.com/linux-pam/linux-pam/blob/955b3e2f100205be2db4358e9c812de2ae453b8e/libpam/pam_audi...
--
Thomas Munro
http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
2018-11-24 10:45 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] PG Bug reporting form <noreply@postgresql.org>
2018-11-24 11:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-24 21:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
@ 2018-11-25 20:09 ` Albert Schabhuetl <albert_schabhuetl@yahoo.de>
2018-11-25 22:30 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
0 siblings, 1 reply; 8+ messages in thread
From: Albert Schabhuetl @ 2018-11-25 20:09 UTC (permalink / raw)
To: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>; Thomas Munro <thomas.munro@enterprisedb.com>
NULL vs hostname for PAM_RHOST:
My understanding is that the purpose of the PAM configuration parameter pam_use_hostname is to avoid the adverse effects of DNS queries if set to 0. Thus if pam_use_hostname is 0, PAM_RHOST shall be NULL for domain socket connections, just like it is the case for TCP connections.
>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.
regards,Albert
Am Samstag, 24. November 2018, 22:58:01 MEZ hat Thomas Munro <thomas.munro@enterprisedb.com> Folgendes geschrieben:
On Sun, Nov 25, 2018 at 12:57 AM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> It seems we shouldn't be passing a bogus hostname in PAM_RHOST.
I wonder if we should simply not set PAM_RHOST for Unix sockets, since
(in the words of the Linux PAM man page) "[i]n some applications,
PAM_RHOST may be NULL", or set it to the hostname of the local
machine, since in a general sense it is "the hostname of the machine
from which the PAM_RUSER entity is requesting service" (Linux PAM) and
"[t]he name of the applicant's host" (OpenPAM). The latter doesn't
seem great because it means that a PAM module loses the ability to
distinguish this case from the IP case, so I think the former is
probably better. I haven't managed to find anything explicit about
the expected value of PAM_RHOST for Unix sockets in either the Linux
PAM or OpenPAM projects.
I wonder if anyone out there has come to rely on the value "[local]"
that PostgreSQL generates for this case (ie in a custom PAM module or
script executed with pam_exec.so), and would get upset if we changed
it. Seems pretty unlikely.
The comments for pg_getnameinfo_all() could probably do with a mention
of the special value written to "node" for Unix sockets.
Some relevant code:
We can see that linux-audit only starts trying to resolve host if you
didn't also pass in an address:
https://github.com/linux-audit/audit-userspace/blob/e42602b7b246ae62e7a12e9cd91f0ac37b1b1968/lib/aud...
We can also see that linux-pam always passes NULL as an address:
https://github.com/linux-pam/linux-pam/blob/955b3e2f100205be2db4358e9c812de2ae453b8e/libpam/pam_audi...
--
Thomas Munro
http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
2018-11-24 10:45 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] PG Bug reporting form <noreply@postgresql.org>
2018-11-24 11:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-24 21:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-25 20:09 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Albert Schabhuetl <albert_schabhuetl@yahoo.de>
@ 2018-11-25 22:30 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-26 14:02 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Munro @ 2018-11-25 22:30 UTC (permalink / raw)
To: Albert Schabhuetl <albert_schabhuetl@yahoo.de>; +Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
On Mon, Nov 26, 2018 at 9:10 AM Albert Schabhuetl
<albert_schabhuetl@yahoo.de> wrote:
> NULL vs hostname for PAM_RHOST:
>
> My understanding is that the purpose of the PAM configuration parameter pam_use_hostname is to avoid the adverse effects of DNS queries if set to 0. Thus if pam_use_hostname is 0, PAM_RHOST shall be NULL for domain socket connections, just like it is the case for TCP connections.
It doesn't set it to NULL for TCP connections. It tells PostgreSQL
not to bother resolving the name to an address. We can't do much
about it if your PAM implementation decides to resolve it anyway. I
suppose we could have an option not to set it at all, even for TCP.
But the main thing that I think we need to change here to address your
complaint is the Unix socket case, because we're passing a
non-hostname in a context that expects a hostname, which is silly and
generates entirely bogus DNS lookups.
Here's a test:
In pg_hba.conf I put these lines:
local all all pam
pamservice="foo"
host all all 127.0.0.1/32 pam
pamservice="foo"
In /etc/pam.d/foo I put these lines:
auth optional pam_exec.so /tmp/spy_script.sh
auth required pam_permit.so
In /tmp/spy_script.sh I put these lines, and made it executable:
#!/bin/bash
echo "PAM_USER=$PAM_USER, PAM_RHOST=$PAM_RHOST" > /tmp/spy_script.out
$ psql -h localhost postgres munro
-> PAM_USER=munro, PAM_RHOST=127.0.0.1
$ psql postgres munro
-> PAM_USER=munro, PAM_RHOST=[local]
Now in pg_hba.conf I add pam_use_hostname=1 to the end of both lines...
$ psql -h localhost postgres munro
-> PAM_USER=munro, PAM_RHOST=localhost
$ psql postgres munro
-> PAM_USER=munro, PAM_RHOST=[local]
> >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=
--
Thomas Munro
http://www.enterprisedb.com
Attachments:
0001-Don-t-set-PAM_RHOST-for-Unix-sockets.patch (application/octet-stream, 1.6K) download
From e02fda966877e80c75884f4940d24dacbfe595bd Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@enterprisedb.com>
Date: Mon, 26 Nov 2018 11:14:16 +1300
Subject: [PATCH] Don't set PAM_RHOST for Unix sockets.
Since commit 2f1d2b7a we have set PAM_RHOST to "[local]" for Unix
sockets. This caused Linux PAM's libaudit integeration to make DNS
requests for that name. It's not exactly clear what value PAM_RHOST
should have in that case, but it seems clear that we shouldn't set it
to an unresolvable value.
Back-patch to 9.6. Bug #15520.
Author: Thomas Munro
Reported-by: Albert Schabhuetl
Discussion: https://postgr.es/m/15520-4c266f986998e1c5%40postgresql.org
---
src/backend/libpq/auth.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 4f9d697d6da..57725fd9dda 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -2219,15 +2219,18 @@ CheckPAMAuth(Port *port, const char *user, const char *password)
return STATUS_ERROR;
}
- retval = pam_set_item(pamh, PAM_RHOST, hostinfo);
-
- if (retval != PAM_SUCCESS)
+ if (port->hba->conntype != ctLocal)
{
- ereport(LOG,
- (errmsg("pam_set_item(PAM_RHOST) failed: %s",
- pam_strerror(pamh, retval))));
- pam_passwd = NULL;
- return STATUS_ERROR;
+ retval = pam_set_item(pamh, PAM_RHOST, hostinfo);
+
+ if (retval != PAM_SUCCESS)
+ {
+ ereport(LOG,
+ (errmsg("pam_set_item(PAM_RHOST) failed: %s",
+ pam_strerror(pamh, retval))));
+ pam_passwd = NULL;
+ return STATUS_ERROR;
+ }
}
retval = pam_set_item(pamh, PAM_CONV, &pam_passw_conv);
--
2.19.1
* Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
2018-11-24 10:45 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] PG Bug reporting form <noreply@postgresql.org>
2018-11-24 11:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-24 21:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-25 20:09 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Albert Schabhuetl <albert_schabhuetl@yahoo.de>
2018-11-25 22:30 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
@ 2018-11-26 14:02 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2018-11-27 00:39 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
0 siblings, 1 reply; 8+ messages in thread
From: Peter Eisentraut @ 2018-11-26 14:02 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@enterprisedb.com>; Albert Schabhuetl <albert_schabhuetl@yahoo.de>; +Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
2018-11-24 10:45 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] PG Bug reporting form <noreply@postgresql.org>
2018-11-24 11:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-24 21:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-25 20:09 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Albert Schabhuetl <albert_schabhuetl@yahoo.de>
2018-11-25 22:30 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-26 14:02 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
@ 2018-11-27 00:39 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-28 02:03 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Munro @ 2018-11-27 00:39 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Albert Schabhuetl <albert_schabhuetl@yahoo.de>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
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
Attachments:
0001-Don-t-set-PAM_RHOST-for-Unix-sockets-v2.patch (application/octet-stream, 2.7K) download
From 752fdc47dfa3889dc10bc97b44760a37869bd4e4 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@enterprisedb.com>
Date: Mon, 26 Nov 2018 11:14:16 +1300
Subject: [PATCH] Don't set PAM_RHOST for Unix sockets.
Since commit 2f1d2b7a we have set PAM_RHOST to "[local]" for Unix
sockets. This caused Linux PAM's libaudit integration to make DNS
requests for that name. It's not exactly clear what value PAM_RHOST
should have in that case, but it seems clear that we shouldn't set it
to an unresolvable name, so don't do that.
Back-patch to 9.6. Bug #15520.
Author: Thomas Munro
Reviewed-by: Peter Eisentraut
Reported-by: Albert Schabhuetl
Discussion: https://postgr.es/m/15520-4c266f986998e1c5%40postgresql.org
---
src/backend/libpq/auth.c | 50 ++++++++++++++++++++++++----------------
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 4f9d697d6da..ff0832dba8b 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -2162,18 +2162,6 @@ CheckPAMAuth(Port *port, const char *user, const char *password)
{
int retval;
pam_handle_t *pamh = NULL;
- char hostinfo[NI_MAXHOST];
-
- retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
- hostinfo, sizeof(hostinfo), NULL, 0,
- port->hba->pam_use_hostname ? 0 : NI_NUMERICHOST | NI_NUMERICSERV);
- if (retval != 0)
- {
- ereport(WARNING,
- (errmsg_internal("pg_getnameinfo_all() failed: %s",
- gai_strerror(retval))));
- return STATUS_ERROR;
- }
/*
* We can't entirely rely on PAM to pass through appdata --- it appears
@@ -2219,15 +2207,37 @@ CheckPAMAuth(Port *port, const char *user, const char *password)
return STATUS_ERROR;
}
- retval = pam_set_item(pamh, PAM_RHOST, hostinfo);
-
- if (retval != PAM_SUCCESS)
+ if (port->hba->conntype != ctLocal)
{
- ereport(LOG,
- (errmsg("pam_set_item(PAM_RHOST) failed: %s",
- pam_strerror(pamh, retval))));
- pam_passwd = NULL;
- return STATUS_ERROR;
+ char hostinfo[NI_MAXHOST];
+ int flags;
+
+ if (port->hba->pam_use_hostname)
+ flags = 0;
+ else
+ flags = NI_NUMERICHOST | NI_NUMERICSERV;
+
+ retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0,
+ flags);
+ if (retval != 0)
+ {
+ ereport(WARNING,
+ (errmsg_internal("pg_getnameinfo_all() failed: %s",
+ gai_strerror(retval))));
+ return STATUS_ERROR;
+ }
+
+ retval = pam_set_item(pamh, PAM_RHOST, hostinfo);
+
+ if (retval != PAM_SUCCESS)
+ {
+ ereport(LOG,
+ (errmsg("pam_set_item(PAM_RHOST) failed: %s",
+ pam_strerror(pamh, retval))));
+ pam_passwd = NULL;
+ return STATUS_ERROR;
+ }
}
retval = pam_set_item(pamh, PAM_CONV, &pam_passw_conv);
--
2.19.1
* Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
2018-11-24 10:45 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] PG Bug reporting form <noreply@postgresql.org>
2018-11-24 11:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-24 21:57 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-25 20:09 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Albert Schabhuetl <albert_schabhuetl@yahoo.de>
2018-11-25 22:30 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-26 14:02 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2018-11-27 00:39 ` Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
@ 2018-11-28 02:03 ` Thomas Munro <thomas.munro@enterprisedb.com>
0 siblings, 0 replies; 8+ messages in thread
From: Thomas Munro @ 2018-11-28 02:03 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Albert Schabhuetl <albert_schabhuetl@yahoo.de>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Tue, Nov 27, 2018 at 1:39 PM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> 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:
> > > $ 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.
Pushed, and back-patched to 9.6. I wondered whether a documentation
change was warranted, but the special "[local]" value wasn't
documented in the first place, and it shouldn't really surprise anyone
that there is no remote host information for a local connection. A
release note about the change seems sufficient.
Thanks for the report.
--
Thomas Munro
http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2018-11-28 02:03 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-11-24 10:45 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] PG Bug reporting form <noreply@postgresql.org>
2018-11-24 11:57 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-24 21:57 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-25 20:09 ` Albert Schabhuetl <albert_schabhuetl@yahoo.de>
2018-11-25 22:30 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-26 14:02 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2018-11-27 00:39 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-11-28 02:03 ` Thomas Munro <thomas.munro@enterprisedb.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox