Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local]
От | Thomas Munro |
---|---|
Тема | Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] |
Дата | |
Msg-id | CAEepm=016cNC9+Lj_xQOwL+B1XaoofQB8E_qLgPTzea=KfBeWg@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local]
|
Список | pgsql-bugs |
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-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
В списке pgsql-bugs по дате отправления: