From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allowing to create LEAKPROOF functions to non-superuser |
Date: | 2021-04-25 10:24:19 |
Message-ID: | 20210425102419.GA2217680@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 19, 2021 at 05:38:43PM -0400, Stephen Frost wrote:
> > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient for
> > > >> setting LEAKPROOF.
> I'm not really sure that attaching it to pg_read_all_data makes sense..
>
> In general, I've been frustrated by the places where we lump privileges
> together rather than having a way to distinctly GRANT capabilities
> independently- that's more-or-less exactly what lead me to work on
> implementing the role system in the first place, and later the
> predefined roles.
This would be no more lumpy than e.g. pg_read_all_stats. However, I could
live with a separate pg_change_leakproof (or whatever name).
> Here's what I'd ask Andrey- what's the actual use-case here? Are these
> cases where users are actually adding new functions which they believe
> are leakproof where those functions don't require superuser already to
> be created? Clearly if they're in a untrusted language and you have to
> be a superuser to install them in the first place then they should just
> mark the function as leakproof when they install it. If these are
> trusted language functions, I'd be curious to actually see them as I
> have doubts about if they're actually leakproof..
>
> Or is the actual use-case here that they just want to mark functions we
> know aren't leakproof as leakproof anyway because they aren't getting
> the performance they want?
Hearing those answers would be interesting, but it shouldn't change decisions.
A reasonable person can write an actually-leakproof function and wish to mark
it LEAKPROOF, independent of whether that happened in the case that prompted
this thread.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2021-04-25 11:10:35 | Re: Allowing to create LEAKPROOF functions to non-superuser |
Previous Message | Sven Klemm | 2021-04-25 10:20:06 | Re: Fix dropped object handling in pg_event_trigger_ddl_commands |