Re: pgsql: Add new GUC createrole_self_grant.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Add new GUC createrole_self_grant.
Date: 2023-01-11 21:00:26
Message-ID: 668179.1673470826@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> If you want to make safe a SECURITY DEFINER function written using sql
> or plpgsql, you either have to schema-qualify every single reference
> or, more realistically, attach a SET clause to the function to set the
> search_path to a sane value during the time that the function is
> executing. The problem here can be handled the same way, except that
> it's needed in a vastly more limited set of circumstances: you have to
> be calling a SECURITY DEFINER function that will execute CREATE ROLE
> as a non-superuser (and that user then needs to be sensitive to the
> value of this GUC in some security-relevant way). It might be good to
> document this -- I just noticed that the CREATE FUNCTION page has a
> section on "Writing SECURITY DEFINER Functions Safely" which talks
> about dealing with the search_path issues, and it seems like it would
> be worth adding a sentence or two there to talk about this.

OK, I'd be satisfied with that.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2023-01-11 21:16:24 Re: pgsql: Add new GUC createrole_self_grant.
Previous Message Tom Lane 2023-01-11 20:55:10 pgsql: Improve handling of inherited GENERATED expressions.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-01-11 21:03:42 Re: Can we let extensions change their dumped catalog schemas?
Previous Message Tom Lane 2023-01-11 20:58:11 Re: ATTACH PARTITION seems to ignore column generation status