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
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. |
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 |