Обсуждение: BUG #5458: Permission check is skipped by inheritance

The following bug has been logged online:

Bug reference:      5458
Logged by:          Takahiro Itagaki
Email address:      itagaki.takahiro@oss.ntt.co.jp
PostgreSQL version: 9.0beta1
Operating system:   Linux (maybe ALL)
Description:        Permission check is skipped by inheritance
Details:

Even if a non-superuser who has no permissions on
a parent and a child tables, he can retrieve data
from the parent when the two tables have inheritance
relationship.

The behavior seems to be changed in 9.0.
8.4 returns "permission denied" errors expectedly.

=== test case ===
- 'postgres' is a superuser.
- 'normal' is a non-superuser.

(9.0beta1)
=# CREATE TABLE parent (i integer);
=# CREATE TABLE child (i integer);
=# REVOKE ALL ON parent, child FROM public;
=# SET ROLE normal;
=> SELECT * FROM parent;
ERROR:  permission denied for relation parent
=> SELECT * FROM child;
ERROR:  permission denied for relation child
=> SET ROLE postgres;
=# ALTER TABLE child INHERIT parent;
=# SET ROLE normal;
=> SELECT * FROM parent;  -- ???
 i
---
(0 rows)

postgres=> SELECT * FROM child;
ERROR:  permission denied for relation child

(8.4.3)
...
=# ALTER TABLE child INHERIT parent;
=# SET ROLE normal;
=> SELECT * FROM parent;
ERROR:  permission denied for relation parent
=> SELECT * FROM child;
ERROR:  permission denied for relation child

"Takahiro Itagaki" <itagaki.takahiro@oss.ntt.co.jp> writes:
> Even if a non-superuser who has no permissions on
> a parent and a child tables, he can retrieve data
> from the parent when the two tables have inheritance
> relationship.

Hmm, the change to not check child permissions is intentional, but
it looks like Peter overdid it ...

2009-10-23 01:24  petere

    * doc/src/sgml/ddl.sgml, src/backend/optimizer/prep/prepunion.c,
    src/test/regress/expected/privileges.out,
    src/test/regress/sql/privileges.sql: When querying a table with
    child tables, do not check permissions on the child tables.  This
    was found to be useless and confusing in virtually all cases, and
    also contrary to the SQL standard.

            regards, tom lane