Re: security_definer_search_path GUC

čt 3. 6. 2021 v 21:11 odesílatel Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
napsal:

>
>
> > On Jun 3, 2021, at 12:06 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >
> >
> >
> > čt 3. 6. 2021 v 20:25 odesílatel Mark Dilger <
> mark(dot)dilger(at)enterprisedb(dot)com> napsal:
> >
> >
> > > 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?
> >
> > I don't think so for immutable strings we need regular expressions.
> Maybe use some special keyword
> >
> > search_path only "pg_catalog"
>
> I think we're trying to solve different problems. I'm trying to allow
> non-superusers to set GUCs while putting constraints on what values they
> choose. You appear to be trying to revoke the ability to set a GUC by
> forcing it to only ever have a single value.
>

My proposal doesn't mean the search_path cannot be changed - it limits
possible values like your patch. Maybe we can get inspiration from
pg_hba.conf

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