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

> > Anybody else want to object to this abbreviation idea ?
> 
> I thought we already agreed to change the names per Peter's suggestion.
> 
> I didn't like the original names whether abbreviated or not ...

Good. I have not seen that agreement, maybe it was implied.
I am not sure whether the feature does not actually present a security 
hole ? Two collaborating users can pass each other their privileges.
I think we might need to guard that feature with a special privilege that 
the function creator needs during creation( e.g. dba).

And why not use the existing "set session authorization ..." syntax?
Because it would remain after function exit? Because it needs dba to execute ? 

Don't misunderstand, I like the feature, but this probably has to be considered.

Andreas

Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
> 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.

> 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.
        regards, tom lane