Christopher Sawtell wrote:
>
> On Fri, 24 Aug 2001 06:52, Zot O'Connor wrote:
> > Other SQL servers have the concept of stored procedures having different
> > permissions.
> >
> > For instance a procedure that can update a table.
> >
> > Since a web site typically connects as the webuser (or equiv postgres
> > user), I do not want to offer update to the webuser.
> >
> > The way I have done this elsewhere is to create a stored procedure that
> > could update the table, and allow the webuser to update the table. The
> > procedure had perms of a user who could update the table, but the
> > webuser could not.
> >
> > How can I do this in Postgres?
>
> By not GRANTing the webuser write permission to the tables in question.
I guess I should have been more clear. I want the webuser to
be able to upadte the table VIA the function, and but not directly.
Currently this does not work, since CREATE FUNCTION acts as any
old function:
zot=# CREATE TABLE testperms (id int4);
CREATE
zot=# CREATE FUNCTION effect_testperms (int4) RETURNS int4 AS 'INSERT INTO testperms
(id) VALUES ($1); RETURN 1;' LANGUAGE 'sql';
SELECT effect_testperms(1);
effect_testperms
------------------
1
(1 row)
zot=# \connect - nobody
You are now connected as new user nobody.
zot=> select * from testperms;
ERROR: testperms: Permission denied.
zot=> SELECT effect_testperms(2);
ERROR: testperms: Permission denied.
zot=>
So it appears that FUCNTION effect_testperms() is taking on
the perms of the user calling it.
So it may be a generic issue with Postgres that other DBMS's
effectively run the stored procedure as SUID-like, in that it
takes on the perms of the owner of the procedure, not the
user calling the procedure.
--
Zot O'Connor
http://www.ZotConsulting.com
http://www.WhiteKnightHackers.com
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
