Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXeIM-0004Nu-F3 for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Sep 2022 07:55:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oXeIK-00082I-Ph for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Sep 2022 07:55:52 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXeIK-000829-E5 for pgsql-hackers@lists.postgresql.org; Mon, 12 Sep 2022 07:55:52 +0000 Received: from smtp-fw-80006.amazon.com ([99.78.197.217]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXeIG-0006cT-QR for pgsql-hackers@lists.postgresql.org; Mon, 12 Sep 2022 07:55:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1662969348; x=1694505348; h=message-id:date:mime-version:subject:to:references:from: in-reply-to; bh=ou38jF6VyNeCEFUKr0PoTFv0GG9WkqzVzRTrB/eWsy8=; b=cS8yeM2klhP2F0pqbeoxhXv6df/eSjiXkChC9xBx0nxp9XPSLQLrwzXi Mw+qhm2KF96jpQR06Wgf5wE6zCLLo0Dgj/H7kUkvLCjKsE2ImJdvFW+dF aIzDMjeA+VI0WrLA4F/sTYfp63UVzLRB2nE0XNcxmDkvF262KHpvV/hLG 8=; X-IronPort-AV: E=Sophos;i="5.93,308,1654560000"; d="scan'208,217";a="128954268" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-iad-1e-90d70b14.us-east-1.amazon.com) ([10.25.36.210]) by smtp-border-fw-80006.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Sep 2022 07:55:32 +0000 Received: from EX13D03EUC003.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1e-90d70b14.us-east-1.amazon.com (Postfix) with ESMTPS id DDA09C0297; Mon, 12 Sep 2022 07:55:30 +0000 (UTC) Received: from [192.168.28.248] (10.43.164.249) by EX13D03EUC003.ant.amazon.com (10.43.164.192) with Microsoft SMTP Server (TLS) id 15.0.1497.38; Mon, 12 Sep 2022 07:55:29 +0000 Content-Type: multipart/alternative; boundary="------------D1upOor4jK6ib39PqL7s0AIZ" Message-ID: <808019e5-5b28-4771-72fb-99e8013fc05e@amazon.com> Date: Mon, 12 Sep 2022 09:55:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf To: Jacob Champion , PostgreSQL Hackers References: <42ec83af-21e4-320a-a973-db4ac1ed053e@timescale.com> Content-Language: en-US From: "Drouvot, Bertrand" In-Reply-To: <42ec83af-21e4-320a-a973-db4ac1ed053e@timescale.com> X-Originating-IP: [10.43.164.249] X-ClientProxiedBy: EX13D08EUC002.ant.amazon.com (10.43.164.124) To EX13D03EUC003.ant.amazon.com (10.43.164.192) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --------------D1upOor4jK6ib39PqL7s0AIZ Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Hi, On 9/10/22 1:21 AM, Jacob Champion wrote: > On 8/19/22 01:12, Drouvot, Bertrand wrote: >> + wstr = palloc((strlen(tok->string + 1) + 1) * sizeof(pg_wchar)); >> + wlen = pg_mb2wchar_with_len(tok->string + 1, >> + wstr, strlen(tok->string + 1)); > The (tok->string + 1) construction comes up often enough that I think it > should be put in a `regex` variable or similar. That would help my eyes > with the (strlen(tok->string + 1) + 1) construction, especially. > > I noticed that for pg_ident, we precompile the regexes per-line and > reuse those in child processes. Whereas here we're compiling, using, and > then discarding the regex for each check. I think the example set by the > pg_ident code is probably the one to follow, unless you have a good > reason not to. Thanks for the feedback. Yeah fully agree. I'll provide a new version that follow the same logic as the pg_ident code. >> +# Testing with regular expression for username >> +reset_pg_hba($node, '/^.*md.*$', 'password'); >> +test_role($node, 'md5_role', 'password from pgpass and regular expression for username', 0); >> + > IMO the coverage for this patch needs to be filled out. Negative test > cases are more important than positive ones for security-related code. Agree, will do. > > Other than that, and Tom's note on potentially expanding this to other > areas, I'll add regexp usage for the database column and also the for the address one when non CIDR is provided (so host name(s)) (I think it also makes sense specially as we don't allow multiple values for this column). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services:https://aws.amazon.com --------------D1upOor4jK6ib39PqL7s0AIZ Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit

Hi,

On 9/10/22 1:21 AM, Jacob Champion wrote:
On 8/19/22 01:12, Drouvot, Bertrand wrote:
+           wstr = palloc((strlen(tok->string + 1) + 1) * sizeof(pg_wchar));
+           wlen = pg_mb2wchar_with_len(tok->string + 1,
+                                       wstr, strlen(tok->string + 1));
The (tok->string + 1) construction comes up often enough that I think it
should be put in a `regex` variable or similar. That would help my eyes
with the (strlen(tok->string + 1) + 1) construction, especially.

I noticed that for pg_ident, we precompile the regexes per-line and
reuse those in child processes. Whereas here we're compiling, using, and
then discarding the regex for each check. I think the example set by the
pg_ident code is probably the one to follow, unless you have a good
reason not to.

Thanks for the feedback.

Yeah fully agree. I'll provide a new version that follow the same logic as the pg_ident code.

+# Testing with regular expression for username
+reset_pg_hba($node, '/^.*md.*$', 'password');
+test_role($node, 'md5_role', 'password from pgpass and regular expression for username', 0);
+
IMO the coverage for this patch needs to be filled out. Negative test
cases are more important than positive ones for security-related code.

Agree, will do.


Other than that, and Tom's note on potentially expanding this to other
areas, 

I'll add regexp usage for the database column and also the for the address one when non CIDR is provided (so host name(s)) (I think it also makes sense specially as we don't allow multiple values for this column).

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
--------------D1upOor4jK6ib39PqL7s0AIZ--