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
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. |
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 |