From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allowing to create LEAKPROOF functions to non-superuser |
Date: | 2021-04-25 18:33:43 |
Message-ID: | 20210425183343.GR20766@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Andrey Borodin (x4mmm(at)yandex-team(dot)ru) wrote:
> > 20 апр. 2021 г., в 02:38, Stephen Frost <sfrost(at)snowman(dot)net> написал(а):
> > 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?
> >
> > If it's the latter, as I suspect it is, then I don't really think the
> > use-case justifies any change on our part- the right answer is to make
> > those functions actually leakproof, or write ones which are.
>
> Customer was restoring pg_dump of on-premise ERP known as 1C (something like TurboTax) with this add-on [0]
>
> CREATE FUNCTION simple1c.date_from_guid(varchar(36)) RETURNS timestamp LANGUAGE plpgsql IMMUTABLE LEAKPROOF STRICT
>
> I'm not 1C-expert (programmed it a bit to get few bucks when I was a student), but seems like this function simple1c.date_from_guid() can be used in DSL queries. It have no obvious side effects. Maybe we could hack it by exploiting timestamp overflow, but I doubt it's practically usable.
Erm, it's very clearly not leakproof and will happily return information
about the value passed in during some error cases...
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2021-04-25 18:40:54 | Re: Allowing to create LEAKPROOF functions to non-superuser |
Previous Message | Tom Lane | 2021-04-25 17:51:29 | Better sanity checking for message length words |