codekingpro/portable-devtools

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>41.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="41.4. Rules on INSERT, UPDATE, and DELETE" /><link rel="next" href="rules-status.html" title="41.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">41.5. Rules and Privileges</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="rules-update.html" title="41.4. Rules on INSERT, UPDATE, and DELETE">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="rules.html" title="Chapter 41. The Rule System">Up</a></td><th width="60%" align="center">Chapter 41. The Rule System</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="rules-status.html" title="41.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">41.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 original5    query get accessed. When update rules are used, this can include write access6    to tables.7</p><p>8    Rewrite rules don't have a separate owner. The owner of9    a relation (table or view) is automatically the owner of the10    rewrite rules that are defined for it.11    The <span class="productname">PostgreSQL</span> rule system changes the12    behavior of the default access control system. With the exception of13    <code class="literal">SELECT</code> rules associated with security invoker views14    (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 the16    privileges of the rule owner, not the user invoking the rule.17    This means that, except for security invoker views, users only need the18    required privileges for the tables/views that are explicitly named in19    their queries.20</p><p>21    For example: A user has a list of phone numbers where some of22    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">26CREATE TABLE phone_data (person text, phone text, private boolean);27CREATE VIEW phone_number AS28    SELECT person, CASE WHEN NOT private THEN phone END AS phone29    FROM phone_data;30GRANT SELECT ON phone_number TO assistant;31</pre><p>32 33    Nobody except that user (and the database superusers) can access the34    <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 the36    <code class="literal">phone_number</code> view. The rule system will rewrite the37    <code class="command">SELECT</code> from <code class="literal">phone_number</code> into a38    <code class="command">SELECT</code> from <code class="literal">phone_data</code>.39    Since the user is the owner of40    <code class="literal">phone_number</code> and therefore the owner of the rule, the41    read access to <code class="literal">phone_data</code> is now checked against the user's42    privileges and the query is permitted. The check for accessing43    <code class="literal">phone_number</code> is also performed, but this is done44    against the invoking user, so nobody but the user and the45    assistant can use it.46</p><p>47    The privileges are checked rule by rule. So the assistant is for now the48    only one who can see the public phone numbers. But the assistant can set up49    another view and grant access to that to the public. Then, anyone50    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 directly52    accesses <code class="literal">phone_data</code>.  (Actually the assistant can, but it will not work since53    every access will be denied during the permission checks.)54    And as soon as the user notices that the assistant opened55    their <code class="literal">phone_number</code> view, the user can revoke the assistant's access. Immediately, any56    access to the assistant's view would fail.57</p><p>58    One might think that this rule-by-rule checking is a security59    hole, but in fact it isn't.   But if it did not work this way, the assistant60    could set up a table with the same columns as <code class="literal">phone_number</code> and61    copy the data to there once per day. Then it's the assistant's own data and62    the assistant can grant access to everyone they want. A63    <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 to65    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 certain68    columns using the technique shown above, they cannot be used to reliably69    conceal the data in unseen rows unless the70    <code class="literal">security_barrier</code> flag has been set.  For example,71    the following view is insecure:72</p><pre class="programlisting">73CREATE VIEW phone_number AS74    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 any77    <code class="command">SELECT</code> from <code class="literal">phone_number</code> into a78    <code class="command">SELECT</code> from <code class="literal">phone_data</code> and add the79    qualification that only entries where <code class="literal">phone</code> does not begin80    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-defined82    function prior to the <code class="function">NOT LIKE</code> expression.83    For example:84</p><pre class="programlisting">85CREATE FUNCTION tricky(text, text) RETURNS bool AS $$86BEGIN87    RAISE NOTICE '% =&gt; %', $1, $2;88    RETURN true;89END;90$$ LANGUAGE plpgsql COST 0.0000000000000000000001;91 92SELECT * 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 be95    printed as a <code class="literal">NOTICE</code>, because the planner will choose to96    execute the inexpensive <code class="function">tricky</code> function before the97    more expensive <code class="function">NOT LIKE</code>.  Even if the user is98    prevented from defining new functions, built-in functions can be used in99    similar attacks.  (For example, most casting functions include their100    input values in the error messages they produce.)101</p><p>102    Similar considerations apply to update rules. In the examples of103    the previous section, the owner of the tables in the example104    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> on106    the <code class="literal">shoelace</code> view to someone else, but only107    <code class="literal">SELECT</code> on <code class="literal">shoelace_log</code>. The rule action to108    write log entries will still be executed successfully, and that109    other user could see the log entries.  But they could not create fake110    entries, nor could they manipulate or remove existing ones.  In this111    case, there is no possibility of subverting the rules by convincing112    the planner to alter the order of operations, because the only rule113    which references <code class="literal">shoelace_log</code> is an unqualified114    <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, the117    <code class="literal">security_barrier</code> attribute should be applied to118    the view.  This prevents maliciously-chosen functions and operators from119    being passed values from rows until after the view has done its work.  For120    example, if the view shown above had been created like this, it would121    be secure:122</p><pre class="programlisting">123CREATE VIEW phone_number WITH (security_barrier) AS124    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 perform127    far worse than views created without this option.  In general, there is128    no way to avoid this: the fastest possible plan must be rejected129    if it may compromise security.  For this reason, this option is not130    enabled by default.131</p><p>132    The query planner has more flexibility when dealing with functions that133    have no side effects.  Such functions are referred to as <code class="literal">LEAKPROOF</code>, and134    include many simple, commonly used operators, such as many equality135    operators.  The query planner can safely allow such functions to be evaluated136    at any point in the query execution process, since invoking them on rows137    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 any139    arguments from the security barrier view do not have to be marked as140    <code class="literal">LEAKPROOF</code> to be pushed down, as they never receive data141    from the view.  In contrast, a function that might throw an error depending142    on the values received as arguments (such as one that throws an error in the143    event of overflow or division by zero) is not leak-proof, and could provide144    significant information about the unseen rows if applied before the security145    view's row filters.146</p><p>147    It is important to understand that even a view created with the148    <code class="literal">security_barrier</code> option is intended to be secure only149    in the limited sense that the contents of the invisible tuples will not be150    passed to possibly-insecure functions.  The user may well have other means151    of making inferences about the unseen data; for example, they can see the152    query plan using <code class="command">EXPLAIN</code>, or measure the run time of153    queries against the view.  A malicious attacker might be able to infer154    something about the amount of unseen data, or even gain some information155    about the data distribution or most common values (since these things may156    affect the run time of the plan; or even, since they are also reflected in157    the optimizer statistics, the choice of plan).  If these types of "covert158    channel" attacks are of concern, it is probably unwise to grant any access159    to the data at all.160</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="41.4. Rules on INSERT, UPDATE, and DELETE">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="rules.html" title="Chapter 41. The Rule System">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="rules-status.html" title="41.6. Rules and Command Status">Next</a></td></tr><tr><td width="40%" align="left" valign="top">41.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 16.3 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 41.6. Rules and Command Status</td></tr></table></div></body></html>