Re: "setuid" functions, a solution to the RI privilege problem

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(at)gmx(dot)net>
> To: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)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(at)rice(dot)edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005