begriffs open source - ai-pg/blob - full-docs/html/rules-privileges.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>39.5. Rules and Privileges</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="rules-update.html" title="39.4. Rules on INSERT, UPDATE, and DELETE" /><link rel="next" href="rules-status.html" title="39.6. Rules and Command Status" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">39.5. Rules and Privileges</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="rules-update.html" title="39.4. Rules on INSERT, UPDATE, and DELETE">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="rules.html" title="Chapter 39. The Rule System">Up</a></td><th width="60%" align="center">Chapter 39. The Rule System</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="rules-status.html" title="39.6. Rules and Command Status">Next</a></td></tr></table><hr /></div><div class="sect1" id="RULES-PRIVILEGES"><div class="titlepage"><div><div><h2 class="title" style="clear: both">39.5. Rules and Privileges <a href="#RULES-PRIVILEGES" class="id_link">#</a></h2></div></div></div><a id="id-1.8.6.10.2" class="indexterm"></a><a id="id-1.8.6.10.3" class="indexterm"></a><p>
   3     Due to rewriting of queries by the <span class="productname">PostgreSQL</span>
   4     rule system, other tables/views than those used in the original
   5     query get accessed. When update rules are used, this can include write access
   6     to tables.
   7 </p><p>
   8     Rewrite rules don't have a separate owner. The owner of
   9     a relation (table or view) is automatically the owner of the
  10     rewrite rules that are defined for it.
  11     The <span class="productname">PostgreSQL</span> rule system changes the
  12     behavior of the default access control system. With the exception of
  13     <code class="literal">SELECT</code> rules associated with security invoker views
  14     (see <a class="link" href="sql-createview.html" title="CREATE VIEW"><code class="command">CREATE VIEW</code></a>),
  15     all relations that are used due to rules get checked against the
  16     privileges of the rule owner, not the user invoking the rule.
  17     This means that, except for security invoker views, users only need the
  18     required privileges for the tables/views that are explicitly named in
  19     their queries.
  20 </p><p>
  21     For example: A user has a list of phone numbers where some of
  22     them are private, the others are of interest for the assistant of the office.
  23     The user can construct the following:
  24
  25 </p><pre class="programlisting">
  26 CREATE TABLE phone_data (person text, phone text, private boolean);
  27 CREATE VIEW phone_number AS
  28     SELECT person, CASE WHEN NOT private THEN phone END AS phone
  29     FROM phone_data;
  30 GRANT SELECT ON phone_number TO assistant;
  31 </pre><p>
  32
  33     Nobody except that user (and the database superusers) can access the
  34     <code class="literal">phone_data</code> table. But because of the <code class="command">GRANT</code>,
  35     the assistant can run a <code class="command">SELECT</code> on the
  36     <code class="literal">phone_number</code> view. The rule system will rewrite the
  37     <code class="command">SELECT</code> from <code class="literal">phone_number</code> into a
  38     <code class="command">SELECT</code> from <code class="literal">phone_data</code>.
  39     Since the user is the owner of
  40     <code class="literal">phone_number</code> and therefore the owner of the rule, the
  41     read access to <code class="literal">phone_data</code> is now checked against the user's
  42     privileges and the query is permitted. The check for accessing
  43     <code class="literal">phone_number</code> is also performed, but this is done
  44     against the invoking user, so nobody but the user and the
  45     assistant can use it.
  46 </p><p>
  47     The privileges are checked rule by rule. So the assistant is for now the
  48     only one who can see the public phone numbers. But the assistant can set up
  49     another view and grant access to that to the public. Then, anyone
  50     can see the <code class="literal">phone_number</code> data through the assistant's view.
  51     What the assistant cannot do is to create a view that directly
  52     accesses <code class="literal">phone_data</code>.  (Actually the assistant can, but it will not work since
  53     every access will be denied during the permission checks.)
  54     And as soon as the user notices that the assistant opened
  55     their <code class="literal">phone_number</code> view, the user can revoke the assistant's access. Immediately, any
  56     access to the assistant's view would fail.
  57 </p><p>
  58     One might think that this rule-by-rule checking is a security
  59     hole, but in fact it isn't.   But if it did not work this way, the assistant
  60     could set up a table with the same columns as <code class="literal">phone_number</code> and
  61     copy the data to there once per day. Then it's the assistant's own data and
  62     the assistant can grant access to everyone they want. A
  63     <code class="command">GRANT</code> command means, <span class="quote">“<span class="quote">I trust you</span>”</span>.
  64     If someone you trust does the thing above, it's time to
  65     think it over and then use <code class="command">REVOKE</code>.
  66 </p><p>
  67     Note that while views can be used to hide the contents of certain
  68     columns using the technique shown above, they cannot be used to reliably
  69     conceal the data in unseen rows unless the
  70     <code class="literal">security_barrier</code> flag has been set.  For example,
  71     the following view is insecure:
  72 </p><pre class="programlisting">
  73 CREATE VIEW phone_number AS
  74     SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';
  75 </pre><p>
  76     This view might seem secure, since the rule system will rewrite any
  77     <code class="command">SELECT</code> from <code class="literal">phone_number</code> into a
  78     <code class="command">SELECT</code> from <code class="literal">phone_data</code> and add the
  79     qualification that only entries where <code class="literal">phone</code> does not begin
  80     with 412 are wanted.  But if the user can create their own functions,
  81     it is not difficult to convince the planner to execute the user-defined
  82     function prior to the <code class="function">NOT LIKE</code> expression.
  83     For example:
  84 </p><pre class="programlisting">
  85 CREATE FUNCTION tricky(text, text) RETURNS bool AS $$
  86 BEGIN
  87     RAISE NOTICE '% =&gt; %', $1, $2;
  88     RETURN true;
  89 END;
  90 $$ LANGUAGE plpgsql COST 0.0000000000000000000001;
  91
  92 SELECT * FROM phone_number WHERE tricky(person, phone);
  93 </pre><p>
  94     Every person and phone number in the <code class="literal">phone_data</code> table will be
  95     printed as a <code class="literal">NOTICE</code>, because the planner will choose to
  96     execute the inexpensive <code class="function">tricky</code> function before the
  97     more expensive <code class="function">NOT LIKE</code>.  Even if the user is
  98     prevented from defining new functions, built-in functions can be used in
  99     similar attacks.  (For example, most casting functions include their
 100     input values in the error messages they produce.)
 101 </p><p>
 102     Similar considerations apply to update rules. In the examples of
 103     the previous section, the owner of the tables in the example
 104     database could grant the privileges <code class="literal">SELECT</code>,
 105     <code class="literal">INSERT</code>, <code class="literal">UPDATE</code>, and <code class="literal">DELETE</code> on
 106     the <code class="literal">shoelace</code> view to someone else, but only
 107     <code class="literal">SELECT</code> on <code class="literal">shoelace_log</code>. The rule action to
 108     write log entries will still be executed successfully, and that
 109     other user could see the log entries.  But they could not create fake
 110     entries, nor could they manipulate or remove existing ones.  In this
 111     case, there is no possibility of subverting the rules by convincing
 112     the planner to alter the order of operations, because the only rule
 113     which references <code class="literal">shoelace_log</code> is an unqualified
 114     <code class="literal">INSERT</code>.  This might not be true in more complex scenarios.
 115 </p><p>
 116     When it is necessary for a view to provide row-level security, the
 117     <code class="literal">security_barrier</code> attribute should be applied to
 118     the view.  This prevents maliciously-chosen functions and operators from
 119     being passed values from rows until after the view has done its work.  For
 120     example, if the view shown above had been created like this, it would
 121     be secure:
 122 </p><pre class="programlisting">
 123 CREATE VIEW phone_number WITH (security_barrier) AS
 124     SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';
 125 </pre><p>
 126     Views created with the <code class="literal">security_barrier</code> may perform
 127     far worse than views created without this option.  In general, there is
 128     no way to avoid this: the fastest possible plan must be rejected
 129     if it may compromise security.  For this reason, this option is not
 130     enabled by default.
 131 </p><p>
 132     The query planner has more flexibility when dealing with functions that
 133     have no side effects.  Such functions are referred to as <code class="literal">LEAKPROOF</code>, and
 134     include many simple, commonly used operators, such as many equality
 135     operators.  The query planner can safely allow such functions to be evaluated
 136     at any point in the query execution process, since invoking them on rows
 137     invisible to the user will not leak any information about the unseen rows.
 138     Further, functions which do not take arguments or which are not passed any
 139     arguments from the security barrier view do not have to be marked as
 140     <code class="literal">LEAKPROOF</code> to be pushed down, as they never receive data
 141     from the view.  In contrast, a function that might throw an error depending
 142     on the values received as arguments (such as one that throws an error in the
 143     event of overflow or division by zero) is not leakproof, and could provide
 144     significant information about the unseen rows if applied before the security
 145     view's row filters.
 146 </p><p>
 147     For example, an index scan cannot be selected for queries on security
 148     barrier views (or tables with row-level security policies) if an
 149     operator used in the <code class="literal">WHERE</code> clause is associated with the
 150     operator family of the index, but its underlying function is not marked
 151     <code class="literal">LEAKPROOF</code>. The <a class="xref" href="app-psql.html" title="psql"><span class="refentrytitle"><span class="application">psql</span></span></a> program's
 152     <code class="command"><a class="link" href="app-psql.html#APP-PSQL-META-COMMAND-DAO">\dAo+</a></code>
 153     meta-command is useful to list operator families and determine which of
 154     their operators are marked as leakproof.
 155 </p><p>
 156     It is important to understand that even a view created with the
 157     <code class="literal">security_barrier</code> option is intended to be secure only
 158     in the limited sense that the contents of the invisible tuples will not be
 159     passed to possibly-insecure functions.  The user may well have other means
 160     of making inferences about the unseen data; for example, they can see the
 161     query plan using <code class="command">EXPLAIN</code>, or measure the run time of
 162     queries against the view.  A malicious attacker might be able to infer
 163     something about the amount of unseen data, or even gain some information
 164     about the data distribution or most common values (since these things may
 165     affect the run time of the plan; or even, since they are also reflected in
 166     the optimizer statistics, the choice of plan).  If these types of "covert
 167     channel" attacks are of concern, it is probably unwise to grant any access
 168     to the data at all.
 169 </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="rules-update.html" title="39.4. Rules on INSERT, UPDATE, and DELETE">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="rules.html" title="Chapter 39. The Rule System">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="rules-status.html" title="39.6. Rules and Command Status">Next</a></td></tr><tr><td width="40%" align="left" valign="top">39.4. Rules on <code class="command">INSERT</code>, <code class="command">UPDATE</code>, and <code class="command">DELETE</code> </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 39.6. Rules and Command Status</td></tr></table></div></body></html>