On Sat, 25 Aug 2001 16:42, Zot O'Connor wrote:
> 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.