Re: security_definer_search_path GUC

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Marko Tiikkaja <marko(at)joh(dot)to>, Joel Jacobson <joel(at)compiler(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Chapman Flack <chap(at)anastigmatix(dot)net>
Subject: Re: security_definer_search_path GUC
Date: 2021-06-03 18:25:13
Message-ID: 501677FA-DD44-4724-885C-E49E03CAAA4F@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Jun 3, 2021, at 9:38 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
> This design looks good for extensions, but I am not sure if it is good for users. Some declarative way without necessity to programming or install some extension can be nice.

I agree, though "some declarative way" is a bit vague. I've had ideas that perhaps superusers should be able to further restrict the [min,max] fields of int and real GUCs. Since -1 is sometimes used to mean "disabled", syntax to allow specifying a set might be necessary, something like [-1, 60..600]. For text and enum GUCs, perhaps a set of regexps would work, some being required to match and others being required not to match, such as:

search_path !~ '\mcustomerx\M'
search_path ~ '^pg_catalog,'

If we did something like this, we'd need it to play nicely with other filters provided by extensions, because I'm reasonably sure not all filters could be done merely using set notation and regular expression syntax. In fact, I find it hard to convince myself that set notation and regular expression syntax would even be useful in a large enough number of cases to be worth implementing. What are your thought on that?


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-06-03 18:29:35 Re: CALL versus procedures with output-only arguments
Previous Message Tom Lane 2021-06-03 18:14:41 Re: SSL SNI