Re: BUG #13651: trigger security invoker attack

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.