Prev: [BUG] SECURITY DEFINER on call handler makes daemon crash
Next: [HACKERS] 9.0 release notes done
From: Josh Berkus on 19 Mar 2010 23:27
On 3/19/10 5:18 AM, Tom Lane wrote:
>> When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
>> > it makes server process crashed.
>
> So don't do that. Whatever possessed you to think that's a sensible
> idea anyway?

PATIENT: Doctor, it hurts when I do this!

DOCTOR: So stop doing that.

;-)


--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: KaiGai Kohei on 22 Mar 2010 21:40
(2010/03/20 13:37), Tom Lane wrote:
> KaiGai Kohei<kaigai(a)kaigai.gr.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(a)ak.jp.nec.com>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: [BUG] SECURITY DEFINER on call handler makes daemon crash
Next: [HACKERS] 9.0 release notes done