On Fri, Sep 08, 2000 at 07:14:54PM +0200, Peter Eisentraut wrote:
> Date: Wed, 6 Sep 2000 16:19:08 +0200 (CEST)
> From: Peter Eisentraut <peter_e@gmx.net>
> To: PostgreSQL Development <pgsql-hackers@postgresql.org>
> Subject: "setuid" functions, a solution to the RI privilege problem
>
> With the code cleanup that is just coming through it is now easily
> possible to change the current user id during a session/connection. Hence
> we can now attack the issue of "setuid" functions, which would also
> provide a means to circumvent the well-known RI privilege problem.
>
This sounds good.
> I haven't looked closely, but I envision it working like this: Add a
> boolean attribute to pg_proc, maybe "setuid", but I'd rather avoid that
> name. If it is false then everything happens as usual. If it is true then
> the function manager saves the uid before the function call, sets the
> current uid to the uid of the function creator, and restores it
> afterwards. It might end up touching only a few dozen lines in fmgr.c.
>
Good for functions. Rather than a boolean, how about something to store
the three standard defined behaviors DEFINER,INVOKER,IMPLEMENTATION
DEFINED: "proauth" int, with #DEFINES, perhaps? Or, we could store
the userid that this procedure will run as, with null signifying
invoker. (BTW, that's the first time I've seen 'IMPLEMENTATION DEFINED'
in a standard leaking out into the defined grammar!)
I have some concerns about views, see below.
>
> For those interested in the standards, I append here a relevant section.
> Note that it actually requires SQL language functions to be "setuid" by
> default, but I think we can safely ignore that little artifact.
>
Well, currently, views access the tables in their FROM clause with the
priviliges of the creating user, which means 'setuid' by default. As I
recently found out, subselects in a view definition do _not_ run as the
creating user, however.
I wonder if your approach might also be useful for views? I realize this
is off topic for your suggestion for functions. And I have a sneaking
suspicion that the only fix for VIEWs requires the planner rewrite Tom's
been working on.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
