Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 12, 2012 at 5:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, the just-code-defensively option is worth considering too.
> After rereading this thread, I think I agree with Kevin as well. ...
> Having said that, I do believe that answer is to some extent a
> cop-out.
I agree with that --- doing nothing at all doesn't seem like the best
option here.
> ... on the flip side, the C code could - not to
> put too fine a point on it - be relying on just about anything.
And with that too. The STRICT option is a fairly obvious security
hazard, but who's to say there are not others? I think it'd be easier
to make a case for forbidding a non-superuser from altering *any*
property of a C function. I'd rather start from the point of allowing
only what is clearly safe than disallowing only what is clearly unsafe.
Taking a step or two back, I think that the real use-case we should
be considering here is allowing non-superusers to own (or at least
install) extensions that contain C functions. We would probably want
the non-superuser to be able to drop the extension again, maybe
ALTER EXTENSION SET SCHEMA, maybe ALTER EXTENSION OWNER ... and likely
not too darn much else. Fooling with any of the contained objects
doesn't seem like something we want to permit, since it's likely that
something like a datatype is going to have dependencies on not just
specific objects' properties but their interrelationships.
One possible approach to that is to say that the nominal owner of such
an extension only owns the extension itself, and ownership of the
contained objects is held by, say, the bootstrap superuser. There are
other ways too of course, but this way would bypass the problem of
figuring out how to restrict what an object's nominal owner can do
to it.
regards, tom lane
