From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, 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:40:17 |
Message-ID: | 17926.1394649617@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
I do not put any stock in the notion of "constrained superuser".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Atri Sharma | 2014-03-12 18:45:08 | Re: GSoC 2014 |
Previous Message | Josh Berkus | 2014-03-12 18:32:06 | Re: db_user_namespace a "temporary measure" |