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

> > I am not sure whether the feature does not actually present a security 
> > hole ? Two collaborating users can pass each other their privileges.
> 
> I don't see any (new) security risk here.  Code written by one user can
> be executed with the privileges of another --- so what?  That's the
> situation now, with non-setuid functions.

Hmm? A non-setuid function can execute code written by another user,
but is only allowed to do things the "invoker" has privileges for.
Thus it is a convenience, but does not allow the invoker to do anything
he could not type himself.
Not so with setuid functions, that is exactly why they are handy.
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".

> 
> > And why not use the existing "set session authorization ..." syntax?
> 
> That syntax implies setting authorization permanently (for the rest of
> the session).  If we take over that syntax to mean local privilege
> change inside a function, then it'd be impossible to let a function do a
> global change in the future.  Not sure if we ever want that, but I don't
> think we should foreclose the possibility by using the same syntax to
> mean two different things.

Yes, I was not sure about the intended standards scope of a "set session auth..." 
when called inside a function.

Andreas

Zeugswetter Andreas SB writes:

> Hmm? A non-setuid function can execute code written by another user,
> but is only allowed to do things the "invoker" has privileges for.
> Thus it is a convenience, but does not allow the invoker to do anything
> he could not type himself.
> Not so with setuid functions, that is exactly why they are handy.
> 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".

SQL99 has an answer for this:

[11.49 GR1]
        1) If R is a schema-level routine, then a privilege descriptor           is created that defines the EXECUTE
privilegeon R to the           <authorization identifier> that owns the schema that includes R.           The grantor
forthe privilege descriptor is set to the special           grantor value "_SYSTEM". This privilege is grantable if and
only          if one of the following is satisfied:
 
           a) R is an SQL routine and all of the privileges necessary             for the <authorization identifier> to
successfullyexecute             the <SQL procedure statement> contained in the <routine             body> are
grantable.The necessary privileges include the             EXECUTE privilege on every subject routine of every <routine
           invocation> contained in the <SQL procedure statement>.
 

What this means (to me) is that unless you have grantable privileges for
all the things that your function does, you can't grant the EXECUTE
privilege to anyone.

This rule, while logical, isn't exactly pleasant, since we can hardly
evaluate statically what a function will do (shades of the halting
problem).

I think your concern is valid.  Maybe we can do this:

1.  The proposed commands only work in "setuid" functions (like in Unix)

2.  To create a setuid function you need some privilege.

Part 2 will be a problem, but both the implementation process and the
implementation itself might terminate in finite time.  ;-)

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