Thread: Re: AW: AW: AW: [PATCH] Re: Setuid functions

Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
> Without making the "definer" need an additional grant for creating such 
> a function, it would be like giving him all the privs he has 
> "with grant option".

Hmm ... interesting analogy, but does it hold water?  The GRANT OPTION
stuff implies the right to pass on your privileges to someone else
*permanently*.  A setuid function only lets someone else do the same
things you can do at the time it is called.  There's nothing there that
couldn't be done by having the one user ask the other to do something
using an outside-the-database communication channel.  So I really don't
see a security issue.

I also don't see any privilege of this type in SQL92 (which does have
the concept of setuid functions, in the form of modules).
        regards, tom lane

Tom Lane writes:

> I also don't see any privilege of this type in SQL92 (which does have
> the concept of setuid functions, in the form of modules).

SQL99 has setuid functions in the form of setuid functions, with a syntax
like CREATE FUNCTION .... SECURITY { INVOKER | DEFINER } (too lazy to look
up the details).  There were some peculiar differences IIRC, such as
trigger functions executing with the permission of the trigger creator
(which is yet different).

Modules are more like "packages", AFAICT.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

I updated the patch to use the SET AUTHORIZATION { INVOKER | DEFINER }
terminology. Also, the function owner is now determined and saved at compile
time (no gotchas here, right?). It is located at

http://volpe.home.mindspring.com/pgsql/set_auth.patch

Mark