Thread: Execute permsissions on fuctions

Execute permsissions on fuctions

From
"Zot O'Connor"
Date:
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


Re: Execute permsissions on fuctions

From
"Zot O'Connor"
Date:
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


Re: Execute permsissions on fuctions

From
"Dmitry G. Mastrukov" Дмитрий Геннадьевич Мастрюков
Date:
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




Re: Execute permsissions on fuctions

From
Christopher Sawtell
Date:
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.