Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)

Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm not entirely following here.  If the function is coded in C,
> then it can pretty much do what it pleases independently of what
> user ID is thought to be executing it at the SQL level.  That
> would really only matter if you were doing some SQL stuff via the
> SPI interface
Yeah, there is a lot of SPI through cached prepared statements.
> if that's the case, couldn't the C function set the appropriate
> role to use for itself, anyway?
I suppose it could, though I never really thought about that aspect
of the issue before.
> (In other words, it's not that hard to build a "RUN AS other-user"
> feature into a C function, even without any support from the rest
> of the system.)
Similar to what Stephen says in his post that came through while I
was typing this, I would be less comfortable with this being a
hand-rolled feature of individual C functions than having some more
systematic way to handle it.  Even if there is the possibility that
someone could subvert the more systematic way of doing things with
clever C code, I think the systematic approach reduces risk from
error and would tend to make hostile code in C functions stand out
more.  And having the information at the catalog level would make
the intended usages easier to manage.
-Kevin