On Wednesday, February 20, 2019 5:24:17 PM CET Tom Lane wrote:
> Pierre Ducroquet <p.p...@pinaraf.info> writes:
> > For simple functions like enum_eq/enum_ne, marking them leakproof is an
> > obvious fix (patch attached to this email, including also textin/textout).
>
> This is not nearly as "obvious" as you think. See prior discussions,
> notably
> https://www.postgresql.org/message-id/flat/31042.1546194242%40sss.pgh.pa.us
>
> Up to now we've taken a very strict definition of what leakproofness
> means; as Noah stated, if a function can throw errors for some inputs,
> it's not considered leakproof, even if those inputs should never be
> encountered in practice. Most of the things we've been willing to
> mark leakproof are straight-line code that demonstrably can't throw
> any errors at all.
>
> The previous thread seemed to have consensus that the hazards in
> text_cmp and friends were narrow enough that nobody had a practical
> problem with marking them leakproof --- but we couldn't define an
> objective policy statement that would allow making such decisions,
> so nothing's been changed as yet. I think it is important to have
> an articulable policy about this, not just a seat-of-the-pants
> conclusion about the risk level in a particular function.
>
> regards, tom lane
I undestand these decisions, but it makes RLS quite fragile, with numerous un-
documented side-effects. In order to save difficulties from future users, I
wrote this patch to the documentation, listing the biggest restrictions I hit
with RLS so far.
Regards
Pierre
>From 050c9777cbe417bd53a17043b24928ba5c037250 Mon Sep 17 00:00:00 2001
From: Pierre Ducroquet <pina...@pinaraf.info>
Date: Thu, 21 Feb 2019 15:46:59 +0100
Subject: [PATCH] Document some of the row-level security limitations
RLS relies a lot on marking functions (and thus operators) LEAKPROOF.
The current policy in PostgreSQL is extremely strict, not allowing
functions that could, for instance, leak the input size through a
malloc() call. While strong on the security side, this policy has
side effects that are not documented currently and make RLS much
harder to implement than simply adding policies on the tables.
---
doc/src/sgml/ref/create_policy.sgml | 30 ++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/ref/create_policy.sgml b/doc/src/sgml/ref/create_policy.sgml
index 2e1229c4f9..372b2935ea 100644
--- a/doc/src/sgml/ref/create_policy.sgml
+++ b/doc/src/sgml/ref/create_policy.sgml
@@ -595,7 +595,35 @@ AND
user-defined functions which might not be trustworthy. However,
functions and operators marked by the system (or the system
administrator) as <literal>LEAKPROOF</literal> may be evaluated before
- policy expressions, as they are assumed to be trustworthy.
+ policy expressions, as they are assumed to be trustworthy. Please note that
+ marking functions as <literal>LEAKPROOF</literal> on the default pg_catalog
+ is done very carefully, thus preventing at least the following features to
+ work or to achieve the usually expected level of performance in default
+ settings:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ for the following types, most operators and functions are not marked
+ as <literal>LEAKPROOF</literal>: arrays, enums, ranges
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ full-text search: operators and functions are not
+ <literal>LEAKPROOF</literal>,
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ functional indexes on non-<literal>leakproof</literal> functions are not
+ considered when executing queries and enforcing policies.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ Any query using these features on a table with a policy can not use
+ indexes other than the ones required to enforce the policy.
</para>
<para>
--
2.20.1
