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 1oWbIQ-0007E8-T7 for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Sep 2022 10:31:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oWbIP-0003rN-0V for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Sep 2022 10:31:37 +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 1oWbIO-0003rE-KK for pgsql-hackers@lists.postgresql.org; Fri, 09 Sep 2022 10:31:36 +0000 Received: from smtp-fw-80006.amazon.com ([99.78.197.217]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWbIH-0007KR-LP for pgsql-hackers@lists.postgresql.org; Fri, 09 Sep 2022 10:31:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1662719490; x=1694255490; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to; bh=t/8F5FybwIAkQZZCU7P9J4aIfkqtMq6AYVZgdgYtx+c=; b=HbM/L5n7Bab9CaqT5sd+F2J84xF7QGGn5xVOoz1qZA6fwZHHEdFQ5lm+ mrrugJaaFqhpaJ/A3FnDWEL2Yo3TEMWbPMFARbr83wns2/EKDYknA0zOs wsf8ZUhtIe0kTJ5G25+iN5eZCp4EIdJ4fVQ8Xz/QQfzgKcOd4p/vKQ5LR 0=; X-IronPort-AV: E=Sophos;i="5.93,302,1654560000"; d="scan'208,217";a="128336376" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-iad-1a-e823fbde.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; 09 Sep 2022 10:31:12 +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-1a-e823fbde.us-east-1.amazon.com (Postfix) with ESMTPS id C52F1C0A37; Fri, 9 Sep 2022 10:31:10 +0000 (UTC) Received: from [192.168.2.242] (10.43.165.214) by EX13D03EUC003.ant.amazon.com (10.43.164.192) with Microsoft SMTP Server (TLS) id 15.0.1497.38; Fri, 9 Sep 2022 10:31:09 +0000 Content-Type: multipart/alternative; boundary="------------SFGujUkL60IM5QUOUvd09twQ" Message-ID: <1128e76f-e828-b579-4646-05e8cb021d0e@amazon.com> Date: Fri, 9 Sep 2022 12:31:08 +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.1 Subject: Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf Content-Language: en-US To: Tom Lane , Jacob Champion CC: PostgreSQL Hackers References: <4177827.1662684400@sss.pgh.pa.us> From: "Drouvot, Bertrand" In-Reply-To: <4177827.1662684400@sss.pgh.pa.us> X-Originating-IP: [10.43.165.214] X-ClientProxiedBy: EX13D12EUC004.ant.amazon.com (10.43.164.129) 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 --------------SFGujUkL60IM5QUOUvd09twQ Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Hi, On 9/9/22 2:46 AM, Tom Lane wrote: > 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. Thank you both for your feedback. > 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 that's a fair point, I'll look at it. >> 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. > Agree that it seems unlikely but maybe we could add a new GUC to turn the regex usage on the hba file on/off (and use off as the default)? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services:https://aws.amazon.com --------------SFGujUkL60IM5QUOUvd09twQ Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit

Hi,

On 9/9/22 2:46 AM, Tom Lane wrote: 
Jacob Champion <jchampion@timescale.com> writes:

On Fri, Aug 19, 2022 at 1:13 AM Drouvot, Bertrand <bdrouvot@amazon.com> 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.

    

    
Thank you both for your feedback.

    

    

      
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 that's a fair point, I'll look at it.
    

    

      

        
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.



    

    
Agree that it seems unlikely but maybe we could add a new GUC to
      turn the regex usage on the hba file on/off (and use off as the
      default)?

    

    Regards,

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

  


--------------SFGujUkL60IM5QUOUvd09twQ--