From 050c9777cbe417bd53a17043b24928ba5c037250 Mon Sep 17 00:00:00 2001 From: Pierre Ducroquet 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 LEAKPROOF 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 LEAKPROOF 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: + + + + + for the following types, most operators and functions are not marked + as LEAKPROOF: arrays, enums, ranges + + + + + full-text search: operators and functions are not + LEAKPROOF, + + + + + functional indexes on non-leakproof functions are not + considered when executing queries and enforcing policies. + + + + + Any query using these features on a table with a policy can not use + indexes other than the ones required to enforce the policy. -- 2.20.1