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
