From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:16:24 |
Message-ID: | CA+TgmoYSh1Zi0UH77dre-+PHUyWkYcD2bbGBFcCeAEMsdDjcjw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Wed, Jan 11, 2023 at 4:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
OK, I'll draft a patch tomorrow.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2023-01-11 22:10:07 | Re: pgsql: Doc: add XML ID attributes to <sectN> and <varlistentry> tags. |
Previous Message | Tom Lane | 2023-01-11 21:00:26 | Re: pgsql: Add new GUC createrole_self_grant. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-11 21:18:34 | Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode |
Previous Message | Robert Haas | 2023-01-11 21:13:01 | Re: doc: mentioned CREATE+ATTACH PARTITION as an alternative to CREATE TABLE..PARTITION OF |