On Mon, Jan 16, 2023 at 10:33 AM David G. Johnston
wrote:
> I’m moving on as well. Go with what you have. I have my personal
> understanding clarified at this point. If the docs need more work people
> will ask questions to help guide such work.
Yeah, I hope so.
It's becoming increasingly
On Monday, January 16, 2023, Robert Haas wrote:
>
>
> I don't really think there's too much wrong with what I wrote in the
> patch as proposed, and I would like to get it committed and move on
> without getting drawn into a wide-ranging discussion of every way in
> which we might be able to
On Sat, Jan 14, 2023 at 8:12 PM David G. Johnston
wrote:
> OK, given all of that, I suggest reworking the first paragraph of security
> definer functions safely to something like the following:
>
> (Replace: Because a SECURITY DEFINER function is executed with the privileges
> of the user that
On Sat, Jan 14, 2023 at 6:12 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> While the function owner has their own pg_db_role_setting preference for
> this setting,
>
Should we be pointing out that if the role with CREATEROLE isn't also a
LOGIN role then there is little point to
On Sat, Jan 14, 2023 at 5:31 PM Robert Haas wrote:
> On Fri, Jan 13, 2023 at 8:29 PM David G. Johnston
> wrote:
> >> The point of the security definer section is to explain how to safely
> write
> >> security definer functions that you grant to less privileged users
> >
> > Yeah, we are really
On Fri, Jan 13, 2023 at 8:29 PM David G. Johnston
wrote:
>> The point of the security definer section is to explain how to safely write
>> security definer functions that you grant to less privileged users
>
> Yeah, we are really good at "how".
>
> +If the security definer function intends to
On Fri, Jan 13, 2023 at 4:46 PM Andres Freund wrote:
>
> I don't really see what that has to do with the topic at hand, unless you
> want
> to suggest removing the entire section about how to write secure security
> definer functions?
>
Not remove, but I'm not seeing why the introduction of
Hi,
On 2023-01-12 18:15:50 -0700, David G. Johnston wrote:
> On Thu, Jan 12, 2023 at 8:11 AM Robert Haas wrote:
>
> > On Wed, Jan 11, 2023 at 7:53 PM David G. Johnston
> > wrote:
> > > Justed wanted to chime in and say Robert has eloquently put into words
> > much of what I have been thinking
On Thu, Jan 12, 2023 at 8:11 AM Robert Haas wrote:
> On Wed, Jan 11, 2023 at 7:53 PM David G. Johnston
> wrote:
> > Justed wanted to chime in and say Robert has eloquently put into words
> much of what I have been thinking here, and that I concur that guiding the
> DBA to use care with the
On Wed, Jan 11, 2023 at 7:53 PM David G. Johnston
wrote:
> Justed wanted to chime in and say Robert has eloquently put into words much
> of what I have been thinking here, and that I concur that guiding the DBA to
> use care with the power they have been provided is a sane position to take.
>
>
On Wed, Jan 11, 2023 at 2:16 PM Robert Haas wrote:
> On Wed, Jan 11, 2023 at 4:00 PM Tom Lane wrote:
> > Robert Haas 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
On Wed, Jan 11, 2023 at 4:00 PM Tom Lane wrote:
> Robert Haas 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
> >
Robert Haas 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
On Tue, Jan 10, 2023 at 10:25 PM Tom Lane wrote:
> > Of course, if it's possible for a non-CREATEROLE user to set the value
> > that a CREATEROLE user experiences, that'd be more of a problem --
>
> That's exactly the case I'm worried about, and it's completely reachable
> if a CREATEROLE user
Robert Haas writes:
> On Tue, Jan 10, 2023 at 9:40 PM Tom Lane wrote:
>> The scenario I'm worried about could be closed, mostly, if we were willing
>> to invent an intermediate GUC privilege level "can be set interactively
>> but only by CREATEROLE holders" ("PGC_CRSET"?).
> Of course, if it's
On Tue, Jan 10, 2023 at 9:40 PM Tom Lane wrote:
> Yeah. I concur that a SUSET GUC isn't much fun for a non-superuser
> CREATEROLE holder who might wish to adjust the default behavior they get.
> I also concur that it seems a bit far-fetched that a CREATEROLE holder
> might create a SECURITY
Robert Haas writes:
> On Tue, Jan 10, 2023 at 8:47 PM Tom Lane wrote:
>> [ squint ... ] Are you sure it's not a security *hazard*, though?
> I think you have to squint pretty hard to find a security hazard here.
Maybe, but I'd be sad if somebody manages to find one after this is
out in the
On Tue, Jan 10, 2023 at 8:47 PM Tom Lane wrote:
> [ squint ... ] Are you sure it's not a security *hazard*, though?
I think you have to squint pretty hard to find a security hazard here.
The effect of this GUC is to control the set of privileges that a
CREATEROLE user automatically grants to
18 matches
Mail list logo
