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=3N2sA8NKxTTobOLYwZjO=z2n_pQ0P5Fra3Znb5W190cA@mail.gmail.com
Ответ на
Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] (Albert Schabhuetl)
Список
Дерево обсуждения
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] Thomas Munro <thomas.munro@enterprisedb.com>
Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] Albert Schabhuetl <albert_schabhuetl@yahoo.de>
Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local] Thomas Munro <thomas.munro@enterprisedb.com>
On Mon, Nov 26, 2018 at 9:10 AM Albert Schabhuetl 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
В списке pgsql-bugs по дате отправления
От: Albert Schabhuetl
Дата:
От: Feike Steenbergen
Дата: