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

Email was fried, so one more time...

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

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

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 the SQL-session is created, the
SQL-session user identifier in the new SQL-session context is set
to the current user 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 a new pair of identifiers is immediately
appended to the authorization stack such that:

- The user identifier is the newly initialized SQL-session user
identifier.

- The role name is the current role name of the SQL-session
context that was active when the SQL-session caused the
execution of the <routine body>.

The identifiers in this new entry of the authorization stack
are then modified depending on whether the SQL-invoked routine
is an SQL routine or an external routine. If the SQL-invoked
routine is an SQL 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 the routine authorization
and the user identifier is set to null.

If the SQL-invoked routine is an external routine, then the
identifiers are determined according to the external security
characteristic of the SQL-invoked routine:
- If the external security characteristic is DEFINER, then:

o If the routine authorization identifier 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 routine authorization
identifier and the user identifier is set to the null value.

- If the external security characteristic is INVOKER, then the
identifiers remain unchanged.

- If the external security characteristic is 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(at)gmx(dot)net http://yi.org/peter-e/