Re: db_user_namespace a "temporary measure"

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: db_user_namespace a "temporary measure"
Дата
Msg-id 20140312182513.GY12995@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: db_user_namespace a "temporary measure"  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
* Josh Berkus (josh@agliodbs.com) wrote:
> 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

What about "bypass" permissions, ala what superuser does today?  Or are
you saying we'd only need to allow this new kind of role to bypass the
checks in the GRANT/REVOKE system?

> 2 load extensions from a predefined .so directory / list

This would obviously have to be a curated list that avoids things like
'adminpack'...

> 3 create/modify untrusted language functions

Uhh, I don't believe RDS allows you to do this..?

> 4 create per-database users and change their settings

Presumably just for the 'local' DB?

> 5 change database settings (SET stuff)

This can be done by the database-owner already, no?

> 6 NOT change their own user settings

Don't think this is quite that simple (passwords?).

> 7 NOT change any global users

What about role membership, wrt local vs. global roles?

> 8 NOT run SET PERSISTENT or other commands with global effect

Indeed, or use 'COPY'..

> Now, obviously permission (3) could be used to escalate a local
> superuser to global superuser permissions, so local superusers aren't
> really a secure concept, unless you don't add any untrusted languages to
> the list of allowed extensions.  Alternately, we could drop (3) from the
> list of features.

That'd certainly be the main issue that I see with this proposal.  Doing
the rest but allowing untrusted languages would just get the naive in
trouble and not help those of us who want this, as we wouldn't be able
to use it.

> Hmmmm. On the other foot, though: all of 1,2,4 and 5 could conceivably
> be done via a set of Security Definer functions loaded into the
> database, with a lot less complexity and security risk.

For my part- I don't see having everyone write their own set of SECURITY
DEFINER functions as being either less complex or less risk.  They're
also a lot less convenient to use.  That's not what RDS did, is it?  No,
and I agree with them on that part.

> On 03/11/2014 09:39 PM, David Johnston wrote:
> > So if dave is already a user in db1 only that specific dave can be made a
> > global user - any other dave would be disallowed.
>
> Correct.  Well, unless the other dave was promoted first.  However, I
> personally don't see any reason why we should even support promoting
> users from local to global.  It adds complexity to the concept, and the
> value of it eludes me.

Agreed.
Thanks,
    Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [bug fix] pg_ctl always uses the same event source
Следующее
От: Tom Lane
Дата:
Сообщение: Re: COPY table FROM STDIN doesn't show count tag