1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>34.4.Rules and Privileges</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="rules.html" title="Chapter34.The Rule System">
<link rel="prev" href="rules-update.html" title="34.3.Rules on INSERT, UPDATE, and DELETE">
<link rel="next" href="rules-status.html" title="34.5.Rules and Command Status">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="rules-privileges"></a>34.4.Rules and Privileges</h2></div></div></div>
<a name="id719036"></a><a name="id719054"></a><p> Due to rewriting of queries by the <span class="productname">PostgreSQL</span>
rule system, other tables/views than those used in the original
query get accessed. When update rules are used, this can include write access
to tables.</p>
<p> Rewrite rules don't have a separate owner. The owner of
a relation (table or view) is automatically the owner of the
rewrite rules that are defined for it.
The <span class="productname">PostgreSQL</span> rule system changes the
behavior of the default access control system. Relations that
are used due to rules get checked against the
privileges of the rule owner, not the user invoking the rule.
This means that a user only needs the required privileges
for the tables/views that he names explicitly in his queries.</p>
<p> For example: A user has a list of phone numbers where some of
them are private, the others are of interest for the secretary of the office.
He can construct the following:
</p>
<pre class="programlisting">CREATE TABLE phone_data (person text, phone text, private boolean);
CREATE VIEW phone_number AS
SELECT person, phone FROM phone_data WHERE NOT private;
GRANT SELECT ON phone_number TO secretary;</pre>
<p>
Nobody except him (and the database superusers) can access the
<code class="literal">phone_data</code> table. But because of the <code class="command">GRANT</code>,
the secretary can run a <code class="command">SELECT</code> on the
<code class="literal">phone_number</code> view. The rule system will rewrite the
<code class="command">SELECT</code> from <code class="literal">phone_number</code> into a
<code class="command">SELECT</code> from <code class="literal">phone_data</code> and add the
qualification that only entries where <code class="literal">private</code> is false
are wanted. Since the user is the owner of
<code class="literal">phone_number</code> and therefore the owner of the rule, the
read access to <code class="literal">phone_data</code> is now checked against his
privileges and the query is permitted. The check for accessing
<code class="literal">phone_number</code> is also performed, but this is done
against the invoking user, so nobody but the user and the
secretary can use it.</p>
<p> The privileges are checked rule by rule. So the secretary is for now the
only one who can see the public phone numbers. But the secretary can setup
another view and grant access to that to the public. Then, anyone
can see the <code class="literal">phone_number</code> data through the secretary's view.
What the secretary cannot do is to create a view that directly
accesses <code class="literal">phone_data</code>. (Actually he can, but it will not work since
every access will be denied during the permission checks.)
And as soon as the user will notice, that the secretary opened
his <code class="literal">phone_number</code> view, he can revoke his access. Immediately, any
access to the secretary's view would fail.</p>
<p> One might think that this rule-by-rule checking is a security
hole, but in fact it isn't. But if it did not work this way, the secretary
could set up a table with the same columns as <code class="literal">phone_number</code> and
copy the data to there once per day. Then it's his own data and
he can grant access to everyone he wants. A
<code class="command">GRANT</code> command means, “<span class="quote">I trust you</span>”.
If someone you trust does the thing above, it's time to
think it over and then use <code class="command">REVOKE</code>.</p>
<p> This mechanism also works for update rules. In the examples of
the previous section, the owner of the tables in the example
database could grant the privileges <code class="literal">SELECT</code>,
<code class="literal">INSERT</code>, <code class="literal">UPDATE</code>, and <code class="literal">DELETE</code> on
the <code class="literal">shoelace</code> view to someone else, but only
<code class="literal">SELECT</code> on <code class="literal">shoelace_log</code>. The rule action to
write log entries will still be executed successfully, and that
other user could see the log entries. But he cannot create fake
entries, nor could he manipulate or remove existing ones.</p>
</div></body>
</html>
|
