Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gR0ju-0004MF-68 for pgsql-bugs@arkaria.postgresql.org; Sun, 25 Nov 2018 20:10:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gR0js-00055G-Qz for pgsql-bugs@arkaria.postgresql.org; Sun, 25 Nov 2018 20:10:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gR0js-000559-7i for pgsql-bugs@lists.postgresql.org; Sun, 25 Nov 2018 20:10:44 +0000 Received: from sonic306-20.consmr.mail.ir2.yahoo.com ([77.238.176.206]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gR0jo-0007Nz-By for pgsql-bugs@lists.postgresql.org; Sun, 25 Nov 2018 20:10:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1543176637; bh=s8+wkpGqbhlRvVcN9xFywARxZNBjyF+0pIVxmyA/ApA=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=lf26HLOqBc9/cqPGexYUWgQ18SaLKv7akM08LBQBz8yyJELK8Jo9KVgrkc4Ih/zUxTsZXRGSbhz3g4U4GrV2ThirkMDPCC9E7gewEa9sjwvhoqqM2/t3kl4lyiwR99qMzYyXnwKgd14QdefjiWXmFDmsiPaoI7+4MmSKCJteRLEkU9bwKysRQLitODL+nFRTUY4DrDZXV+EMPIsYvWerpYCpuX2k6+ug03WmzBKoHaanLGRDjqXZkrocIiDARETSPcvEAHS4rlzdAiMGKrpeAW3VCF0uIxt9lfiQas3kGCmoUT0oq9LU7aVYB07ddvYPeQpjTBoKbbvb9AaCMMOKzQ== X-YMail-OSG: VEk40zkVM1m7QrgvtQqr3bAOLFaOAShG3XPfW0H_KLuFHUlGdUVpO5Qby8A36JG WKODCap_u9oSQPjRAqEfy8_7jmZ_us8v1IP4EwWR7VDBkl.rif5rRr8lrdauS55zsvilUXMq2df_ whGnVpeNpvhwJOqnSpta337Ls1cv8dpnffaPO_3td5auBKy6RBuTTpyUp3.YbEFSEQ160qSXZQRa jrvZ5XwxaRry_cXY4mE6MxW2ImRBeqFB5DZGW57X0Det0Y1CH5Qhyc2FchEVSf.7fPyLdB1Cvpos m5SZyHBr68G9ekhJnIiw2e.4gjmXptz8bEjD5MZe42swzRPE4WSMPMNUhH5gTytbn5VVS1UiiIhC gUG8zaZp04r3AzURWAdT11J4.MQq3iwoBqS79dezlQnDmw1fLfLpUNijWKWgSsV1j4CSvFkBofTg UmZGvqlbfqwL_d8J5_D6uuf97cjpyKrgaf.kIUBkkxb0J8NY1ms5FyeTsSc.nX5Sl.4plW0ZxwN_ ugg2bkq2LbvfafE_p.nKJhAPIkM6KOADhluhrTP.kftoXaqzwVM0dUKJawRxwlSqRoyuvc9k4.Bg B_q4xApkW2VGiUNfvKxVDQLhcsOdLgZLNmTj7w1rdH5PhZne5ZV_nBD25ZzHOwdXNwAJ2IMfLHEX vIxS4IKrkFQVeQM.7hmg7Qjbl.zXnxDiE4XxFduvv6Ou4BWw3VxZdRjCdBvvFTYiqe1GB3qazs8y gmeqkCjU0d42uzWE0D9WTHeFtfYw3TlM2mT1q6QzXsRU0xitBXga9LKXVJoqeCxFCP4KD5BYQYgJ fDiq7aEl19wjgo6HHGKBF5EupYwmmxrWguC5X7fWHDPzRNt.xD602M3W9knfIBQoPVMXDMGv0Zhd 9YHZ8ZJYIqhVe8abIEHlgkOryw4.WZPQb1c3Boybx.5CEHdkiwO9v9YoPitunKAnlUZZR_TCmhkP vTseFGv3f2482ANmJddUbPedDZKGFkvQI_TGw4gevpDwS.MP69RID_EnHIAIWPWGGVNyaB7A0WJ3 8O5NkKFCwD9zuvQ0v5As- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Sun, 25 Nov 2018 20:10:37 +0000 Date: Sun, 25 Nov 2018 20:09:42 +0000 (UTC) From: Albert Schabhuetl To: PostgreSQL mailing lists , Thomas Munro Message-ID: <1818527878.10526478.1543176582167@mail.yahoo.com> In-Reply-To: References: <15520-4c266f986998e1c5@postgresql.org> Subject: Re: BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10526477_1145817484.1543176582165" X-Mailer: WebService/1.1.12729 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Content-Length: 7045 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_10526477_1145817484.1543176582165 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. T= hus if pam_use_hostname is 0, PAM_RHOST shall be NULL for domain socket con= nections, 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 Folgendes geschrieben: =20 =20 On Sun, Nov 25, 2018 at 12:57 AM Thomas Munro 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).=C2=A0 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.=C2=A0 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.=C2=A0 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/e42602b7b246ae62e7a12e9= cd91f0ac37b1b1968/lib/audit_logging.c#L456 We can also see that linux-pam always passes NULL as an address: https://github.com/linux-pam/linux-pam/blob/955b3e2f100205be2db4358e9c812de= 2ae453b8e/libpam/pam_audit.c#L41 --=20 Thomas Munro http://www.enterprisedb.com =20 ------=_Part_10526477_1145817484.1543176582165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
NULL vs hostname for PAM_RHOST:

My understanding is that the purpose of the PAM configuration paramet= er pam_use_hostname is to avoid the adverse effects of DNS queries if set t= o 0. Thus if pam_use_hostname is 0, PAM_RHOST shall be NULL for domain sock= et 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 relea= se notes.

regards,
Albert

=
=20
=20
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 Thom= as Munro
<thomas= .munro@enterprisedb.com> wrote:
> It seems we s= houldn't be passing a bogus hostname in PAM_RHOST.

I wonder if we should simply not set PAM_RHOST for Unix socket= s, since
(in the words of the Linux PAM man page) "[i]n s= ome applications,
PAM_RHOST may be NULL", or set it to th= e hostname of the local
machine, since in a general sense= it is "the hostname of the machine
from which the PAM_RU= SER 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 t= o
distinguish this case from the IP case, so I think the = former is
probably better.  I haven't managed to fin= d anything explicit about
the expected value of PAM_RHOST= for Unix sockets in either the Linux
PAM or OpenPAM proj= ects.

I wonder if anyone out there has= come to rely on the value "[local]"
that PostgreSQL gene= rates 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 ho= st if you
didn't also pass in an address:

https://github.com/linux-audit/audit-use= rspace/blob/e42602b7b246ae62e7a12e9cd91f0ac37b1b1968/lib/audit_logging.c#L4= 56

We can also see that linux-pam = always passes NULL as an address:

h= ttps://github.com/linux-pam/linux-pam/blob/955b3e2f100205be2db4358e9c812de2= ae453b8e/libpam/pam_audit.c#L41
------=_Part_10526477_1145817484.1543176582165--