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 1oWSAT-0005B3-6u for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Sep 2022 00:46:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oWSAQ-0001CH-0G for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Sep 2022 00:46:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWSAP-0001C7-N6 for pgsql-hackers@lists.postgresql.org; Fri, 09 Sep 2022 00:46:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWSAN-0002AG-51 for pgsql-hackers@lists.postgresql.org; Fri, 09 Sep 2022 00:46:45 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2890keR54177828; Thu, 8 Sep 2022 20:46:40 -0400 From: Tom Lane To: Jacob Champion cc: "Drouvot, Bertrand" , PostgreSQL Hackers Subject: Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf In-reply-to: References: Comments: In-reply-to Jacob Champion message dated "Thu, 08 Sep 2022 17:02:00 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4177826.1662684400.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 08 Sep 2022 20:46:40 -0400 Message-ID: <4177827.1662684400@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jacob Champion writes: > On Fri, Aug 19, 2022 at 1:13 AM Drouvot, Bertrand = wrote: >> This is why I think username filtering with regular expressions would >> provide its own advantages. > I think your motivation for the feature is solid. Yeah. I'm not sure that I buy the argument that this is more useful than writing a role name and controlling things with GRANT ROLE, but it's a plausible alternative with properties that might win in some use-cases. So I see little reason not to allow it. I'd actually ask why stop here? In particular, why not do the same with the database-name column, especially since that does *not* have the ability to use roles as a substitute for a wildcard entry? > I think you're going to have to address backwards compatibility > concerns. Today, I can create a role named "/a", and I can put that > into the HBA without quoting it. I'd be unamused if, after an upgrade, > my rule suddenly matched any role name containing an 'a'. Meh ... that concern seems overblown to me. I guess it's possible that somebody has an HBA entry that looks like that, but it doesn't seem very plausible. Note that we made this exact same change in pg_ident.conf years ago, and AFAIR we got zero complaints. > Speaking of partial matches, should this feature allow them? Maybe > rules should have to match the entire username instead, and sidestep > the inevitable "I forgot to anchor my regex" problems? I think the pg_ident.conf precedent is binding on us here. If we make this one work differently, nobody's going to thank us for it, they're just going to wonder "did the left hand not know what the right hand already did?" regards, tom lane