Home • Explore • Blog • CI
☰



postgresql
9th chunk of `doc/src/sgml/ref/create_policy.sgml`
9a48842582a3a46cb49d17b8bc8a2922e128ed67ae433fcc00000001000007dc

<replaceable>expression</replaceable> from RESTRICTIVE UPDATE/ALL policy 1
AND
<replaceable>expression</replaceable> from RESTRICTIVE UPDATE/ALL policy 2
AND
...
AND
(
  <replaceable>expression</replaceable> from PERMISSIVE UPDATE/ALL policy 1
  OR
  <replaceable>expression</replaceable> from PERMISSIVE UPDATE/ALL policy 2
  OR
  ...
)
</programlisting></para>

  </refsect2>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   You must be the owner of a table to create or change policies for it.
  </para>

  <para>
   While policies will be applied for explicit queries against tables
   in the database, they are not applied when the system is performing internal
   referential integrity checks or validating constraints.  This means there are
   indirect ways to determine that a given value exists.  An example of this is
   attempting to insert a duplicate value into a column that is a primary key
   or has a unique constraint.  If the insert fails then the user can infer that
   the value already exists. (This example assumes that the user is permitted by
   policy to insert records which they are not allowed to see.)  Another example
   is where a user is allowed to insert into a table which references another,
   otherwise hidden table.  Existence can be determined by the user inserting
   values into the referencing table, where success would indicate that the
   value exists in the referenced table.  These issues can be addressed by
   carefully crafting policies to prevent users from being able to insert,
   delete, or update records at all which might possibly indicate a value they
   are not otherwise able to see, or by using generated values (e.g., surrogate
   keys) instead of keys with external meanings.
  </para>

  <para>
   Generally, the system will enforce filter conditions imposed using
   security policies prior to qualifications that appear in user queries,
   in order to prevent inadvertent exposure of the protected data to
   user-defined functions
Title: RLS Notes: Ownership, Integrity Checks, and Filter Enforcement
Summary
This section provides important notes regarding Row-Level Security (RLS) policies. It emphasizes that only the table owner can create or modify RLS policies. It clarifies that RLS policies are not enforced during internal referential integrity checks or constraint validations, potentially leading to indirect disclosure of data existence. It suggests crafting policies to prevent insertions, deletions, or updates that might reveal otherwise hidden values, or using generated values. Finally, it mentions that filter conditions from security policies are enforced before user-defined function qualifications to prevent inadvertent data exposure.