Re: Re: Row Level Security − leakproof-ness and performance implications

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Row Level Security − leakproof-ness and performance implications
Date: 2019-02-28 15:49:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com> writes:
> On Thu, Feb 28, 2019 at 9:12 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> So... you're just going to replace ALL error messages of any kind with
>> "ERROR: missing error text" when this option is enabled? That sounds
>> unusable. I mean if I'm reading it right this would get not only
>> messages from SQL-callable functions but also things like "deadlock
>> detected" and "could not read block %u in file %s" and "database is
>> not accepting commands to avoid wraparound data loss in database with
>> OID %u". You can't even shut it off conveniently, because the way

> This makes complete sense to me. The client side of a client/server
> protocol doesn't have any way to fix 'could not read block %u in file
> %s', the client doesn't need that kind of detailed information about a
> server, and in fact that information could be security sensitive.

I agree with Robert that this idea is a nonstarter. Not only is it
a complete disaster from a usability standpoint, but *it does not
fix the problem*. The mere fact that an error occurred, or didn't,
is already an information leak. Sure, you can only extract one bit
per query that way, but a slow leak is still a leak. See the Spectre
vulnerability for a pretty exact parallel.

The direction I think we're going to need to go in is to weaken our
standards for what we'll consider a leakproof function, and/or try
harder to make common WHERE-clause operators leakproof. The thread
over at
raises the question of why we don't expect that *all* indexable
operators are leakproof, at least with respect to the index column
contents. (Failing to distinguish which of the inputs can be
leaked seems like a pretty fundamental mistake in hindsight.
For instance, some opclasses can directly index regex operators,
and one would not wish to give up the ability for a regex operator
to complain about an invalid pattern. But it could be leakproof
with respect to the data side.)

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-02-28 15:58:49 Re: Why don't we have a small reserved OID range for patch revisions?
Previous Message Ildus Kurbangaliev 2019-02-28 15:44:15 Re: [HACKERS] Custom compression methods