Re: Per-role disabling of LEAKPROOF requirements for row-level security?

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Andreas Lind <andreaslindpetersen(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Per-role disabling of LEAKPROOF requirements for row-level security?
Date: 2025-06-23 07:56:19
Message-ID: CAGECzQSgx_GkyyW5SF5Lo6vm4TwJWfdH0VtMaYb3ZKeJ6oE9Sg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 23 Jun 2025 at 09:43, Andreas Lind
<andreaslindpetersen(at)gmail(dot)com> wrote:
>
> Thanks for your replies!
>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> writes:
> > > I'm not sure whether multi-tenant applications fall into the category where
> > > LEAKPROOFness isn't considered important, since security is typically a key
> > > concern for users of such systems.
>
> > Yeah, ISTM that you might as well just disable the RLS policy as
> > ignore leakproofness, because it is completely trivial to examine
> > supposedly-hidden data if you can apply a non-leakproof function
> > to it.
>
> In my case the role is only used by the application code, which
> is reviewed and trusted. So I'm not too concerned about a malicious
> actor using it to apply non-leakproof functions. Or rather, the risk
> of that happening seems much lower than the application accidentally
> mixing data from different tenants by forgetting WHERE tenant_id = ...
> So I'd argue that it can be very valuable to have RLS enabled
> for defense-in-depth even without the leakproof guardrails.

+1 on this usecase. RLS its primary usecase right now is to protect
against arbitrary SQL execution, for which the LEAKPROOF protection
makes sense. But there are quite a lot of people (people building SaaS
apps with a tenant_id column on each table) that would like to use it
as a mechanism to automatically add a filter on each of their queries
in a transaction, to avoid coding errors in their own application. In
your application you can then have a function like,
open_tenant_transaction(). Which basically does: "BEGIN" and "SET
LOCAL tenant_id". And from then on you don't have to worry about.

For that second usecase LEAKPROOF only gets in the way. These people
just want an additional filter to be applied automatically. I've seen
multiple users that tried RLS for this purpose, and switched back to
not doing any RLS because the leakproof protections got in the way of
getting performant queries.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2025-06-23 08:01:23 Improving and extending int128.h to more of numeric.c
Previous Message Jelte Fennema-Nio 2025-06-23 07:44:29 Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx