Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tNDAl-009L9o-TU for pgsql-general@arkaria.postgresql.org; Mon, 16 Dec 2024 15:38:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tNDAj-0086Tq-Eb for pgsql-general@arkaria.postgresql.org; Mon, 16 Dec 2024 15:38:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tNDAi-0086Tf-Vf for pgsql-general@lists.postgresql.org; Mon, 16 Dec 2024 15:38:14 +0000 Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tNDAh-0038jt-CL for pgsql-general@lists.postgresql.org; Mon, 16 Dec 2024 15:38:13 +0000 Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-2a3d8857a2bso1242200fac.1 for ; Mon, 16 Dec 2024 07:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734363490; x=1734968290; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=BTXnKkfROUD27fJjUTm6sVxBZJhjp+B1NdNL41mheB8=; b=I2UeJSdq/TBIrU1rbQIdFY3FG8Oy5YHDygHsJLBskt17UcEn6Vc9TeR2jQm/SEbLwW jy4mZn3yMsNf/tC9Rq8vpEgh72QKb+XCQR8KXeE86Z0ZDydmHJsmsSrt2WlEqIlQySYQ I0HfJ3qG2U5m+zz2I5f4NRMnMTvOHd/F06NsUehksxeGLa0KD7J5lkdW0h5/zu4MJ2F4 VOAqSe5vqjbug/krT/1nqOZZfjmdURpEI+wpJh7SmT9Tbk+xA4O8svm56q5qFvaDXE4X 3YlxWfD2jRXqcID5+FlDapIBs8eXwxMsbrRiOrSDOEXCfWxBgjpdHQbM82By2d9Q2PiX KMsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734363490; x=1734968290; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BTXnKkfROUD27fJjUTm6sVxBZJhjp+B1NdNL41mheB8=; b=RyzYB5z4/wCRQpLLKC/IfOcuQX2NJTrhVn6/mzimGZiAQsYFx5ebltncOiIOogXRMn D7UGb27KPKhNZ9jw4LbSHr9MJjLePiY6CjXw8qP5rC55SRvjx2dI4z2pLMQ70mnWiyNx 9Huh65jTRre/MkH+H25kEJ5UWm1R58Nabrwm8wxQBcjBr2OGrd0pnJRRCYm3hrOy5cl6 oPxU62NBPvulRqjxI3pjAWHrfwidFEYTFr7DvAwigEXVyFKWd2OjrCJpBN1gFOCcWEDP CbjHznQCftoAViMzNvQXecDH4yiE0XJexcYJWbHYl9UOp26GT+/u5Dk0CcZ1YWVOtvOW 6csQ== X-Gm-Message-State: AOJu0Yx0BZaUgGPds5Yxh/pkshEeE8QjFOHHgAZkBBxY5ifzuQ4j/vXB A5ZfM6O+EpsLs4k+XUBm01AsKJdZrvOLdrQrpmiTQ73kz4++FXB1Prru/SfHv9hmEudUhRnpG1O i6ljN0zUmVhxCFoIANSNbv/APlpieQqSQ X-Gm-Gg: ASbGnctJfe7k4zr1KJJMf8FrqQp/BkNAH0sVtyaGfa1RjCDOKkbeW6MYJDlzuM/MFuN RMVXSf9Dk+Rx+DkzpkTLAjFuDqmrW/Ze6VS4cvtY= X-Google-Smtp-Source: AGHT+IFPz/0fPaaZh4j6WoFT0gyeYyk/5T1/P1DDcHWQ+E5ttlOhuZ2J4t4XdbR8Zl8YfaxOfy3btGM+mm7QKTtsLUU= X-Received: by 2002:a05:6871:e7c5:b0:29e:4ba5:4ddc with SMTP id 586e51a60fabf-2a3ac7292ccmr6493485fac.24.1734363490402; Mon, 16 Dec 2024 07:38:10 -0800 (PST) MIME-Version: 1.0 References: <20241213202348.jtchbb2lezbx2re6@hjp.at> <20241216151853.ecl37fqyhwmcdi7i@hjp.at> In-Reply-To: <20241216151853.ecl37fqyhwmcdi7i@hjp.at> From: Ron Johnson Date: Mon, 16 Dec 2024 10:37:59 -0500 Message-ID: Subject: Re: Credcheck- credcheck.max_auth_failure To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000c1c841062964f76d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c1c841062964f76d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 16, 2024 at 10:19=E2=80=AFAM Peter J. Holzer = wrote: > On 2024-12-16 09:17:25 -0500, Ron Johnson wrote: > > Local (socket-based) connections are typically peer-authenticated > > (meaning that authentication is handled by Linux pam). > ^^^ > Is it? I haven't checked the source code, but this doesn't seem > plausible. You can get the uid of a socket peer directly from the > kernel, which can be converted to a user name via getpwuid, and the > mapping to postgresql roles is done via pg_ident.conf. I see no role for > PAM in that path. > https://www.postgresql.org/docs/16/auth-peer.html " The peer authentication method works by obtaining the client's operating system user name from the kernel and using it as the allowed database user name (with optional user name mapping). This method is only supported on local connections. [snip] Peer authentication is only available on operating systems providing the getpeereid() function, the SO_PEERCRED socket parameter, or similar mechanisms. Currently that includes Linux, most flavors of BSD including macOS, and Solaris. " That means pam (and presumably also ldap and sssd), since there must be an OS user with the same name, and OS authentication is handled by pam, ldap and sssd. $ grep peer '$PGDATA'/pg_hba.conf local all all peer > > > Thus, if someone enters too many wrong passwords for a superuser > > account, you should still be able to locally connect to PG. > > True. But the client may not be on the same machine. > > hp > > -- > _ | Peter J. Holzer | Story must make more sense than reality. > |_|_) | | > | | | hjp@hjp.at | -- Charles Stross, "Creative writing > __/ | http://www.hjp.at/ | challenge!" > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000c1c841062964f76d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 16, 2024 at 10:19=E2=80=AFAM = Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
On 2024-12-16 09:17:25 -0500, Ron= Johnson wrote:
> Local (socket-based) connections are typically peer-authenticated
> (meaning that authentication is handled by Linux pam).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^
Is it? I haven't checked the source code, but this doesn't seem
plausible. You can get the uid of a socket peer directly from the
kernel, which can be converted to a user name via getpwuid, and the
mapping to postgresql roles is done via pg_ident.conf. I see no role for PAM in that path.


"
The peer authentication method works by obtaining the client's= operating system user name from the kernel and using it as the allowed dat= abase user name (with optional user name mapping). This method is only supp= orted on local connections.
[snip]
Peer authentication is only available on = operating systems providing the=C2=A0getpeereid()= =C2=A0function, the=C2=A0SO_PEERCRED=C2=A0socket parameter, or similar m= echanisms. Currently that includes=C2=A0Linux, = most flavors of=C2=A0BSD=C2=A0including=C2=A0m= acOS, and=C2=A0Solaris
"

=
That means pam (and presumably also ldap and sssd), since there must b= e an OS user with the same name,=C2=A0and OS authentication is handled by p= am, ldap and sssd.

$ grep= peer '$PGDATA'/pg_hba.conf
local =C2=A0 all=C2=A0 =C2=A0 =C2=A0= all=C2=A0 =C2=A0 =C2=A0 =C2=A0peer
=C2=A0

> Thus, if someone enters too many wrong passwords for a superuser
> account, you should=C2=A0still be able to locally connect to PG.

True. But the client may not be on the same machine.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 hp

--
=C2=A0 =C2=A0_=C2=A0 | Peter J. Holzer=C2=A0 =C2=A0 | Story must make more = sense than reality.
|_|_) |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
| |=C2=A0 =C2=A0| hjp@hjp.a= t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 -- Charles Stross, &q= uot;Creative writing
__/=C2=A0 =C2=A0| http://www.hjp.at/ |=C2=A0 =C2=A0 =C2=A0 =C2=A0challenge!&q= uot;


--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000c1c841062964f76d--