Re: db_user_namespace a "temporary measure"

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, David Johnston <polobo(at)yahoo(dot)com>
Subject: Re: db_user_namespace a "temporary measure"
Date: 2014-03-12 19:03:07
Message-ID: 5320AF6B.7010905@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03/12/2014 11:40 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 03/12/2014 02:09 PM, Josh Berkus wrote:
>>> Well, if you really want my "I want a pony" list:
>>>
>>> Local superusers (maybe this concept needs another name) would be able
>>> to do the following things in a *single* database:
>>>
>>> 1 change permissions for other users on that database and its objects
>>> 2 load extensions from a predefined .so directory / list
>>> 3 create/modify untrusted language functions
>>> 4 create per-database users and change their settings
>>> 5 change database settings (SET stuff)
>>> 6 NOT change their own user settings
>>> 7 NOT change any global users
>>> 8 NOT run SET PERSISTENT or other commands with global effect
>
>> Item 3 gives away the store.
>
> Indeed. If you can do (3), you can break out of any of the other
> constraints. I suspect even (1) and/or (5) would be enough to mount
> trojan-horse attacks against real superusers who visit your database.

... nobody reads my whole post, except Stephen. :-(

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-03-12 19:05:38 Re: db_user_namespace a "temporary measure"
Previous Message Andres Freund 2014-03-12 19:03:01 Re: Replication slots and footguns