On Sat, 2009-10-03 at 09:45 +0300, I wrote:
> So let's get rid of that. Selecting (or in general, operating) on a
> table with children only checks the privileges on that table, not the
> children.
If I'm seeing this right, it's literally a one-line fix. Patch attached
with documentation and test updates.
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index e055518..51d9aef 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -2124,20 +2124,20 @@ VALUES ('New York', NULL, NULL, 'NY');
and rejection that apply during <command>CREATE TABLE</command>.
</para>
- <sect2 id="ddl-inherit-caveats">
- <title>Caveats</title>
-
<para>
- Table access permissions are not automatically inherited. Therefore,
- a user attempting to access a parent table must either have permissions
- to do the same operation on all its child tables as well, or must use the
- <literal>ONLY</literal> notation. When adding a new child table to
- an existing inheritance hierarchy, be careful to grant all the needed
- permissions on it.
+ Note how table access permissions are handled. Querying a parent
+ table can automatically access data in child tables without further
+ access privilege checking. This preserves the appearance that the
+ data is (also) in the parent table. Accessing the child tables
+ directly is, however, not automatically allowed and would require
+ further privileges to be granted.
</para>
+ <sect2 id="ddl-inherit-caveats">
+ <title>Caveats</title>
+
<para>
- More generally, note that not all SQL commands are able to work on
+ Note that not all SQL commands are able to work on
inheritance hierarchies. Commands that are used for data querying,
data modification, or schema modification
(e.g., <literal>SELECT</literal>, <literal>UPDATE</literal>, <literal>DELETE</literal>,
diff --git a/src/backend/optimizer/prep/prepunion.c b/src/backend/optimizer/prep/prepunion.c
index df9eac6..17ddbe2 100644
--- a/src/backend/optimizer/prep/prepunion.c
+++ b/src/backend/optimizer/prep/prepunion.c
@@ -1244,6 +1244,7 @@ expand_inherited_rtentry(PlannerInfo *root, RangeTblEntry *rte, Index rti)
childrte = copyObject(rte);
childrte->relid = childOID;
childrte->inh = false;
+ childrte->requiredPerms = 0;
parse->rtable = lappend(parse->rtable, childrte);
childRTindex = list_length(parse->rtable);
diff --git a/src/test/regress/expected/privileges.out b/src/test/regress/expected/privileges.out
index 16b5581..4decb2b 100644
--- a/src/test/regress/expected/privileges.out
+++ b/src/test/regress/expected/privileges.out
@@ -406,11 +406,22 @@ SELECT fx FROM atestp2; -- ok
----
(0 rows)
-SELECT fy FROM atestp2; -- fail, no privilege on atestc.fy
-ERROR: permission denied for relation atestc
-SELECT atestp2 FROM atestp2; -- fail, no privilege on atestc.fy
-ERROR: permission denied for relation atestc
-SELECT oid FROM atestp2; -- fail, no privilege on atestc.oid
+SELECT fy FROM atestp2; -- ok
+ fy
+----
+(0 rows)
+
+SELECT atestp2 FROM atestp2; -- ok
+ atestp2
+---------
+(0 rows)
+
+SELECT oid FROM atestp2; -- ok
+ oid
+-----
+(0 rows)
+
+SELECT fy FROM atestc; -- fail
ERROR: permission denied for relation atestc
SET SESSION AUTHORIZATION regressuser1;
GRANT SELECT(fy,oid) ON atestc TO regressuser2;
diff --git a/src/test/regress/sql/privileges.sql b/src/test/regress/sql/privileges.sql
index 943fe36..d4f7282 100644
--- a/src/test/regress/sql/privileges.sql
+++ b/src/test/regress/sql/privileges.sql
@@ -277,9 +277,10 @@ GRANT SELECT(fx) ON atestc TO regressuser2;
SET SESSION AUTHORIZATION regressuser2;
SELECT fx FROM atestp2; -- ok
-SELECT fy FROM atestp2; -- fail, no privilege on atestc.fy
-SELECT atestp2 FROM atestp2; -- fail, no privilege on atestc.fy
-SELECT oid FROM atestp2; -- fail, no privilege on atestc.oid
+SELECT fy FROM atestp2; -- ok
+SELECT atestp2 FROM atestp2; -- ok
+SELECT oid FROM atestp2; -- ok
+SELECT fy FROM atestc; -- fail
SET SESSION AUTHORIZATION regressuser1;
GRANT SELECT(fy,oid) ON atestc TO regressuser2;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
