'update' as action of 'insert' rule: permission denied

From: Tim Burgess <tim(at)queens(dot)unimelb(dot)edu(dot)au>
To: pgsql-bugs(at)postgresql(dot)org
Subject: 'update' as action of 'insert' rule: permission denied
Date: 2003-02-10 18:51:13
Message-ID: A102805E-3D28-11D7-A5D5-000393BE2C60@queens.unimelb.edu.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-bugs

Gday All,

I'm surprised I can't find any descriptions of this in the archive
already, since I had imagined it would be a common action, but
apparently not!

Illustration:

As superuser:

create table1 ( test1 integer );
create table2 ( test2 integer );
create user pleb;
grant insert on table1 to pleb;
create rule test_rule as on insert to table1 do update table2 set test2
= 2 where test2 = 0;

As user pleb:

insert into table1 values (1);
ERROR: table1: Permission denied.

However, just to check, if we remove the rule (using DROP RULE) the
INSERT query works fine.
I also wrote a query using 'insert' as the action instead of 'update'
and that worked fine too.
I also tried granting the user pleb update and select permission on
table test2, and that failed in the same way as above.

My impression from the doco is that the permission rules should be
applied _before_ any rule interpretation is applied, and then again as
the rule owner for the queries (extra queries only? this is
unspecified in the doco) that the rule creates. Since the rule owner
in this case is the superuser (correct?), the query should succeed
whether or not the rule is present.

Note that the query succeeds when run as the superuser...

Cheerio!,

Tim Burgess
Queens' College
University of Melbourne

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Panchal, Ritesh 2003-02-10 20:03:41 Database backup
Previous Message Mike Alford 2003-02-10 13:44:22 ODBC and unknown i.p.

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2003-02-10 19:30:52 Re: cvs (7/2/2003) broken?
Previous Message Stephan Szabo 2003-02-10 15:54:56 Re: Referential Integrity