"setuid" functions, a solution to the RI privilege problem - Mailing list pgsql-hackers

Email was fried, so one more time...

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

---------- Forwarded message ----------
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.

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.

As for syntax, we can easily do with the "CREATE FUNCTION WITH" mechanism,
until we implement the standard syntax.

What this means in particular for the RI triggers is that they would then
always execute with the permission of the bootstrap user (usually
"postgres"), which would give them a free ticket. OTOH, that would commit
us that the "postgres" user always has to be a superuser, which should be
okay I should think.

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.

[4.23]        When the <routine body> of an SQL-invoked routine is executed and        the new SQL-session context for
theSQL-session is created, the        SQL-session user identifier in the new SQL-session context is set        to the
currentuser identifier in the SQL-session context that was        active when the SQL-session caused the execution of
the<routine        body>. The authorization stack of this new SQL-session context is        initially set to empty and
anew pair of identifiers is immediately        appended to the authorization stack such that:        -  The user
identifieris the newly initialized SQL-session user           identifier.        -  The role name is the current role
nameof the SQL-session           context that was active when the SQL-session caused the           execution of the
<routinebody>.        The identifiers in this new entry of the authorization stack        are then modified depending
onwhether the SQL-invoked routine        is an SQL routine or an external routine. If the SQL-invoked        routine is
anSQL routine, then, if the routine authorization        identifier is a user identifier, the user identifier is set to
      the routine authorization identifier and the role name is set to        null; otherwise, the role name is set to
theroutine authorization        and the user identifier is set to null.        If the SQL-invoked routine is an
externalroutine, then the        identifiers are determined according to the external security        characteristic of
theSQL-invoked routine:        -  If the external security characteristic is DEFINER, then:           o If the routine
authorizationidentifier is a user identifier,             then the user identifier is set to the routine authorization
          identifier and the role name is set to the null value.           o Otherwise, the role name is set to the
routineauthorization             identifier and the user identifier is set to the null value.        -  If the external
securitycharacteristic is INVOKER, then the           identifiers remain unchanged.        -  If the external security
characteristicis IMPLEMENTATION           DEFINED, then the identifiers are set to implementation-defined
values.

[11.49]        <external security clause> ::=               EXTERNAL SECURITY DEFINER             | EXTERNAL SECURITY
INVOKER            | EXTERNAL SECURITY IMPLEMENTATION DEFINED
 


-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/