On Fri, Aug 2, 2024 at 9:13 AM Joe Conway <m...@joeconway.com> wrote: > > On 8/2/24 11:07, Tom Lane wrote: > > Joe Conway <m...@joeconway.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
