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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, PostgreSQL-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUG] SECURITY DEFINER on call handler makes daemon crash
Date: 2010-03-20 04:37:19
Message-ID: 1315.1269059839@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-03-20 08:49:23 Re: Streaming replication status
Previous Message Bruce Momjian 2010-03-20 04:02:09 9.0 release notes done