Re: [BUG] SECURITY DEFINER on call handler makes daemon crash

(2010/03/20 13:37), Tom Lane wrote:
> KaiGai Kohei<kaigai(at)kaigai(dot)gr(dot)jp> writes:
>> Is it an expected behavior that PostgreSQL tries to execute foo() with
>> privileges of the owner of language call handler because of its security
>> definer property? This server crash is just a result.
>
> A language call handler has no function properties of its own --- which
> is why attaching SECURITY DEFINER to it is both useless and meaningless.
> The appropriate function properties for any call are those of the user
> function being called, which the handler is merely a support for.

OK, I also think the call handlers should work transparently like air.

> You could argue that we should put call handlers into their own table
> instead of pg_proc, since they aren't really user-callable functions;
> that would prevent people from thinking that something like this is
> sane. However, they share just enough infrastructure with real
> functions that it didn't seem worth doing it that way.
>
> I see no value whatsoever in making the world safe for people to attach
> SECURITY DEFINER to handlers. It's an incorrect declaration, and
> superusers need to know better than to declare C functions with
> incorrect properties.

I basically agree that this matter does not happen unless user intend to
assign SECURITY DEFINER attribute on the language call handlers, although
it is nonsense.
The reason why I reported it is that it was not clear for me whether the
development team knows this matter, and I doubted the design we can assign
this nonsense attribute from the perspective of fool-proof.

Fool-proof is a term from human-interface. It tells us manufactured-product
should work safely, even if user tries to abuse it. A microwave-oven does not
work without closing its door, for example.
In my sense, we should care about known matters at least.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>