From: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jacob Champion <jchampion(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf |
Date: | 2022-09-20 11:33:09 |
Message-ID: | e3091081-dc98-7f2b-829f-c247b9337653@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 9/20/22 6:30 AM, Michael Paquier wrote:
> On Tue, Sep 20, 2022 at 12:09:33AM -0400, Tom Lane wrote:
>> You have to assume that somebody (a) has a role or DB name starting
>> with slash, (b) has an explicit reference to that name in their
>> pg_hba.conf, (c) doesn't read the release notes, and (d) doesn't
>> notice that things are misbehaving until after some hacker manages
>> to break into their installation on the strength of the misbehaving
>> entry. OK, I'll grant that the probability of (c) is depressingly
>> close to unity; but each of the other steps seems quite low probability.
>> All four of them happening in one installation is something I doubt
>> will happen.
>
> It is the kind of things that could blow up as a CVE and some bad PR
> for the project, so I cannot get excited about enforcing this new rule
> in an authentication file (aka before a role is authenticated) while
> we are talking about 3~4 code paths (?) that would need an extra check
> to make sure that no instances have such object names.
I also have the feeling that having (a), (b) and (d) is low probability.
That said, If the user "/john" already exists and has a hba entry then
this entry will still match with the patch. Problem is that all the
users that contain "john" would also now match.
But things get worst if say /a is an existing user and hba entry as the
entry would match any users that contains "a" with the patch.
I assume (maybe i should not) that if objects starting with / already
exist there is very good reason(s) behind. Then I don't think that
preventing their creation in the DDL would help (quite the contrary for
the ones that really need them).
It looks to me that adding a GUC (off by default) to enable/disable the
regexp usage in the hba could be a fair compromise. It won't block any
creation starting with a / and won't open more doors (if such objects
exist) by default.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Florin Irion | 2022-09-20 11:33:45 | Re: pg_create_logical_replication_slot argument incongruency |
Previous Message | Melih Mutlu | 2022-09-20 11:00:19 | Re: Summary function for pg_buffercache |