Re: can we mark upper/lower/textlike functions leakproof?

On Fri, Aug 2, 2024 at 9:13 AM Joe Conway <mail(at)joeconway(dot)com> wrote:
>
> On 8/2/24 11:07, Tom Lane wrote:
> > Joe Conway <mail(at)joeconway(dot)com> writes:
> >> <dons flameproof suit>
> >> Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
> >> current behavior, 'lax' allows the 'maybe's to get pushed down, and
> >> 'off' ignores the leakproof attribute entirely and pushes down anything
> >> that merits being pushed?
> >> </dons flameproof suit>
> >
> > So in other words, we might as well just remove RLS.
>
> Perhaps deciding where to draw the line for 'maybe' is too hard, but I
> don't understand how you can say that in a general sense.

I'm more sympathetic to the "maybe" case, but for the "off" proposal I
find myself agreeing with Tom. If you want "off", turn off RLS.

> And even 'off'
> has utility for cases where (1) no logins are allowed except for the app
> (which is quite common in production environments) and no database
> errors are propagated to the end client (again pretty standard best
> practice);

I'm extremely skeptical of this statement, but I've been out of the
full-stack world for a bit. How does a modern best-practice
application hide the fact that it ran into an error and couldn't
complete a query?

> or (2) non-production environments, e.g. for testing or
> debugging; or

Changing the execution behavior between dev and prod seems like an
anti-goal. When would turning this off help you debug something?

> (3) use cases that utilize RLS as a notationally
> convenient filtering mechanism and are not bothered by some leakage in
> the worst case.

Catering to this use case doesn't seem like it should be a priority.
If a security feature is useful for you in a non-security setting,
awesome, but we shouldn't poke holes in it for that situation, nor
should it be surprising if the security gets stronger and becomes
harder to use for non-security.

--Jacob