Thread: Execute permsissions on fuctions
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? Thanks. -- Zot O'Connor http://www.ZotConsulting.com http://www.WhiteKnightHackers.com
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
23 Aug 2001 11:52:25 -0700, Zot O'Connor ____ > 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? > You can do it indirectly. There is patch for 7.1.2 which adds SET AUTHORIZATION INVOKER/DEFINER clause to PLPGSQL. Sorry, I don't remember link, you can find it in -sql or -hackers mailing list archives on June or I can send it to you. Next step is to create some function like (I use here array iterator from <src>/contrib/array) CREATE FUNCTION IS_MEMBER(char(32)) RETURNS bool AS ' DECLARE group_name ALIAS FOR $1;sel INTEGER; BEGINsel := (SELECT COUNT(*) FROM pg_group WHERE grolist *= (SELECT usesysid FROM pg_user WHERE usename = current_user) AND CAST(groname AS char(32)) = group_name); IF sel > 0THEN return true;ELSE return false;END IF; END; ' LANGUAGE 'PLPGSQL'; Now you can do something like IF IS_MEMBER(''<some_group>'') != true AND USER != ''<definer>'' THENreturn NULL; END IF; SET AUTHORIZATION DEFINER; on top of your function. Such thing works fine for me, but I prefer to have clear GRANT EXECUTE syntax with CREATE FUNCTION func (....) AUTH INVOKER/DEFINER; ability. IMHO setuid functions with control of who can execute them are very helpful in implementing database logic. Standart SELECT/UPDATE/DELETE for views/tables often can be weak. When I some time ago asked about GRANT EXECUTE someone (Peter or Tom i cannot recall) told something like "you feel free to send patch to implement such behaviour". Regards, Dmitry
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.