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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 03:56:09
Message-ID: 603c8f071003192056qb443f1cxf4e9a07fdfc5cb70@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 19, 2010 at 10:29 PM, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> 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.

I'm inclined to feel (and Tom's response only reinforces this) that
the actual behavior isn't critical. I'd be happy with (1) executing
foo() with the privileges of the language owner or (2) ignoring the
SECURITY DEFINER attribute in this context and executing foo() without
changing privileges or (3) throwing an error. We should just do
whatever complicates the code the least. Your proposed patch seems
good from that point of view, though I'm not clear on whether it's
otherwise reasonable or which of the above behaviors it actually
implements.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-03-20 04:02:09 9.0 release notes done
Previous Message Josh Berkus 2010-03-20 03:27:15 Re: [BUG] SECURITY DEFINER on call handler makes daemon crash