Greetings,
* Noah Misch (noah@leadboat.com) wrote:
> 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@leadboat.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).
There's been already some disagreements about pg_read_all_stats, so I
don't think that is actually a good model to look at.
I have doubts about users generally being able to write actually
leakproof functions (this case being an example of someone writing a
function that certainly wasn't leakproof but marking it as such
anyway...), though I suppose it's unlikely that it's any worse than the
cases of people writing SECURITY DEFINER functions that aren't careful
enough, of which I've seen plenty of.
I would think the role/capability would be 'pg_mark_function_leakproof'
or similar though, and allow a user who had that role to either create
leakproof functions (provided they have access to create the function in
the first place) or to mark an existing function as leakproof (but
requiring them to be a member of the role which owns the function).
Thanks,
Stephen