Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: albert_schabhuetl(at)yahoo(dot)de, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
Date: 2018-11-24 11:57:37
Message-ID: CAEepm=016cNC9+Lj_xQOwL+B1XaoofQB8E_qLgPTzea=KfBeWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Nov 24, 2018 at 11:46 PM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 15520
> Logged by: Albert Schabhuetl
> Email address: albert_schabhuetl(at)yahoo(dot)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-f5a9c53142c3595fe47ebf5146457c6b
> 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Munro 2018-11-24 21:57:22 Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
Previous Message PG Bug reporting form 2018-11-24 10:45:54 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]