Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)
Date: 2012-07-20 20:28:11
Message-ID: CA+TgmoaCvZ6+wSPuudq7JA_6RCzgwg8kp7J1FryysgqGZcfMFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 20, 2012 at 3:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I don't particularly care for that solution; it seems like a kludge.
>> I've kind of wondered whether we ought to have checks in all the ALTER
>> routines that spit up if you try to ALTER an extension member from any
>> place other than an extension upgrade script... but that still
>> wouldn't prevent the extension owner from dropping the members out of
>> the extension and then modifying them afterwards. I'm not sure we
>> want to prevent that in general, but maybe there could be some
>> locked-down mode that has that effect.
>
> Right, I wasn't too clear about that, but I meant that we'd have some
> sort of locked-down state for an extension that would forbid fooling
> with its contents. For development purposes, or for anybody that "knows
> what they're doing", adding/subtracting/modifying member objects is
> mighty handy. But a non-superuser who's loaded an extension that
> contains C functions ought not have those privileges for it.

I could see having such a mode. I'm not sure that it would eliminate
people's desire to manually give away functions, though. In fact,
thinking about a couple of our customers, I'm pretty sure it wouldn't.
Now whether it's a good idea is another question, but...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniele Varrazzo 2012-07-21 00:08:58 Resetting libpq connections after an app error
Previous Message Andrew Dunstan 2012-07-20 20:21:35 Re: [COMMITTERS] pgsql: Remove prepared transactions from main isolation test schedule.