On Tuesday, September 29, 2015, <digoal@126.com> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 13651
> Logged by: digoal
> Email address: digoal@126.com <javascript:;>
> PostgreSQL version: 9.4.4
> Operating system: CentOS 6.x x64
> Description:
>
> In my database, there have two role, one normal user, one superuser.
>
> postgres=# \dt
> List of relations
> Schema | Name | Type | Owner
> --------+------------------+-------+----------
> public | customer_reviews | table | postgres
> public | t | table | digoal
> public | t1 | table | postgres
> public | t2 | table | postgres
> public | t3 | table | postgres
>
>
>
Elided truncate trigger dropping t1...
> And rule is security.
> postgres=# \c postgres digoal
> You are now connected to database "postgres" as user "digoal".
> postgres=> create rule r1 as on delete to t do instead delete from t1;
> CREATE RULE
> postgres=> delete from t;
> ERROR: permission denied for relation t1
>
>
I'm surprised this works since t1 shouldn't exist...
postgres=> \c postgres postgres
> You are now connected to database "postgres" as user "postgres".
> postgres=# \set VERBOSITY verbose
> postgres=# delete from t;
> ERROR: 42501: permission denied for relation t1
> LOCATION: aclcheck_error, aclchk.c:3371
>
>
But since t1 does exist and t is owned by digoal the fact that this fails
with a permission error is unsurprising. Rules execute as the owner of the
relation to which they are attached in order to facilitate data hiding,
David J.
