From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
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 18:21:19 |
Message-ID: | 5320A59F.6050308@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/12/2014 02:09 PM, Josh Berkus wrote:
> On 03/12/2014 12:22 AM, Magnus Hagander wrote:
>> On Mar 12, 2014 1:46 AM, "Josh Berkus" <josh(at)agliodbs(dot)com> wrote:
>>> Yeah, what we really need is encapsulated per-DB users and local
>>> superusers. I think every agrees that this is the goal, but nobody
>>> wants to put in the work to implement a generalized solution.
>>>
>> Encapsulated would probably be the doable part. But local superuser? Given
>> that a superuser can load and run binaries, how would you propose you
>> restrict that superuser from doing anything they want? And if you don't
>> need that functionality, then hows it really different from being the
>> database owner?
> 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. AFAIK Amazon doesn't load untrusted
languages, period.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-03-12 18:21:21 | Re: [bug fix] pg_ctl always uses the same event source |
Previous Message | Heikki Linnakangas | 2014-03-12 18:13:45 | Re: GIN improvements part2: fast scan |