Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf
От | Drouvot, Bertrand |
---|---|
Тема | Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf |
Дата | |
Msg-id | e3091081-dc98-7f2b-829f-c247b9337653@gmail.com обсуждение исходный текст |
Ответ на | Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf
|
Список | 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
В списке pgsql-hackers по дате отправления: