Re: db_user_namespace a "temporary measure"
От | Andrew Dunstan |
---|---|
Тема | Re: db_user_namespace a "temporary measure" |
Дата | |
Msg-id | 5320A59F.6050308@dunslane.net обсуждение исходный текст |
Ответ на | Re: db_user_namespace a "temporary measure" (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: db_user_namespace a "temporary measure"
|
Список | 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@agliodbs.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
В списке pgsql-hackers по дате отправления: